SSH-keys beheren: veiligheid en best practices

Hoe SSH-keys werken

Een SSH-key is een paar bestanden: een private key die op uw apparaat blijft en een public key die u kopieert naar elke server waarop u wilt inloggen. Wanneer u verbinding maakt, gebruikt de server de public key om een challenge te sturen die alleen de bijbehorende private key kan beantwoorden. De private key verlaat uw apparaat nooit, waardoor er geen geheim over het netwerk wordt verstuurd en een gecompromitteerde server niets bruikbaars kan stelen. Daarom zijn keys veiliger dan wachtwoorden. Het goed beheren van SSH-keys komt neer op vier gewoontes: één key per apparaat, de bestandsrechten die sshd vereist, een ~/.ssh/config-bestand zodat u stopt met het typen van opties, en weten hoe u een key verwijdert op de dag dat een laptop vermist raakt.

Deze handleiding behandelt elke gewoonte op Ubuntu 24.04, hoewel bijna alles hier van toepassing is op elke Linux-server en elke recente OpenSSH.

Eén punt over terminologie voordat we beginnen, omdat dit echte fouten voorkomt. De public key is niet geheim. U kunt deze in een ticket plakken, per e-mail versturen of publiceren, en niemand kan ermee inloggen. De private key is het geheim. Iedereen die dat bestand kopieert, en de passphrase kent als die er is, is voor uw servers gelijk aan u.

Een sleutel aanmaken: ed25519 is de juiste standaard

Voer op uw eigen computer, niet op de server, het volgende uit:

ssh-keygen -t ed25519 -C "laptop"

-t ed25519 kiest het type sleutel. Ed25519 is de moderne standaard: de sleutels zijn kort, snel en worden ondersteund door elke OpenSSH-release sinds 2014. Val alleen terug op ssh-keygen -t rsa -b 4096 wanneer u moet communiceren met een oud apparaat dat ed25519 niet ondersteunt. -C "laptop" stelt een commentaar in. Het commentaar heeft geen cryptografische functie, maar het is de manier waarop u deze sleutel over twee jaar zult herkennen in het bestand authorized_keys van een server; noem het dus naar het apparaat waar de sleutel op staat.

ssh-keygen vraagt waar de sleutel moet worden opgeslagen. Accepteer de standaardlocatie, ~/.ssh/id_ed25519. Vervolgens wordt er gevraagd om een wachtwoordzin. Stel er een in; de sectie over wachtwoordzinnen hieronder legt uit waarom dit u in het dagelijks gebruik niets kost. U eindigt met twee bestanden: ~/.ssh/id_ed25519 is de privésleutel en ~/.ssh/id_ed25519.pub is de publieke sleutel. Bekijk de publieke helft:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

Dit is één regel: het type sleutel, het sleutelmateriaal en uw commentaar. Die regel is wat uiteindelijk op uw servers terechtkomt.

Eén sleutel per apparaat, niet één per server

De vraag die iedereen als eerste stelt: heb ik voor elke server een nieuwe sleutel nodig? Nee. Maak één sleutel aan voor elk apparaat waarop u werkt en plaats die ene publieke sleutel op elke server die het apparaat moet kunnen bereiken. De sleutel identificeert het apparaat. Het bestand authorized_keys op elke server is de lijst met apparaten die toegang hebben.

Dit is het model dat schaalbaar is; de alternatieven falen op voorspelbare wijze. Eén sleutel per server betekent dat een laptop met twintig servers twintig privésleutels bevat, waardoor u het overzicht verliest welke sleutel bij welke server hoort. Eén sleutel die door al uw apparaten wordt gedeeld is nog slechter: wanneer de laptop wordt gestolen, kunt u de laptop niet intrekken zonder ook uzelf buitensluiten van uw desktop, omdat deze dezelfde privésleutel bevatten. U moet dan de sleutel overal vervangen en deze tegelijkertijd naar elk apparaat distribueren.

Met één sleutel per apparaat kost de verloren laptop u slechts één regel per server: verwijder de regel van de laptop uit authorized_keys en elk ander apparaat blijft werken. De opmerking die u instelt met -C zorgt ervoor dat die regel eenvoudig terug te vinden is.

De regel achter dit model: een privésleutel wordt op een apparaat aangemaakt en sterft met dat apparaat. Kopieer nooit een privésleutel naar een tweede machine en upload er nooit een naar een server. Wanneer een nieuw apparaat toegang nodig heeft, genereert u daarop een nieuwe sleutel.

Plaats de publieke sleutel op de server

De eenvoudigste methode is ssh-copy-id, dat standaard wordt meegeleverd met OpenSSH:

ssh-copy-id matt@10.0.0.10

Dit commando logt in met de huidige methode, meestal een wachtwoord, voegt uw publieke sleutel toe aan ~/.ssh/authorized_keys op de server en maakt de map en het bestand aan met de juiste rechten als deze nog niet bestaan. Test de configuratie door een nieuwe SSH-sessie te openen: de server hoort u toegang te verlenen zonder om het wachtwoord van het account te vragen. Als uw sleutel een wachtwoordzin (passphrase) heeft, kan uw eigen machine daar om vragen; die prompt is lokaal en is niet het wachtwoord van de server.

Wanneer inloggen met een wachtwoord al is uitgeschakeld, kan ssh-copy-id geen verbinding maken. U moet de regel dan handmatig toevoegen. Log in via een sessie die nog wel werkt, of via de webconsole van uw provider, en voer het volgende uit op de server:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Plak uw werkelijke publieke sleutel tussen de aanhalingstekens; dit is de volledige regel uit id_ed25519.pub. authorized_keys bevat één publieke sleutel per regel en vormt de volledige toegangsdatabase: het toevoegen van een apparaat betekent een regel toevoegen, en het intrekken van de toegang betekent een regel verwijderen. Op een nieuwe server hoort deze stap thuis in de eerste 10 minuten op een nieuwe VPS, vlak voordat u het inloggen met een wachtwoord uitschakelt.

De rechten die inloggen met een sleutel verhinderen

Dit is de meest voorkomende oorzaak waardoor inloggen met een sleutel mislukt, en het faalt zonder melding aan de clientzijde. sshd draait standaard met StrictModes yes op Ubuntu 24.04, wat betekent dat het weigert een authorized_keys-bestand te gebruiken dat door andere gebruikers bewerkt kan worden. Als het bestand, de ~/.ssh-map of uw thuismap door iemand anders dan uzelf beschrijfbaar is, negeert sshd uw sleutel en valt terug op het vragen om een wachtwoord, zonder uitleg in de client. (De OpenSSH-versie van Ubuntu staat precies één uitzonderlijk geval toe: een bestand dat beschrijfbaar is voor de groep van de eigenaar, mits niemand anders lid is van die groep. Vertrouw hier niet op; houd de onderstaande modi aan.) De reden verschijnt alleen in het logboek van de server:

sudo grep 'Authentication refused' /var/log/auth.log

Op een minimale image zonder rsyslog bestaat auth.log niet; dezelfde regel staat in de journal: sudo journalctl -u ssh | grep 'Authentication refused'.

Authentication refused: bad ownership or modes for file /home/matt/.ssh/authorized_keys

De oplossing bestaat uit twee wijzigingen in de rechten en een controle van het eigenaarschap, uit te voeren op de server als de betreffende gebruiker:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R matt:matt ~/.ssh

De regel om te onthouden: 700 op de .ssh-map, 600 op alles wat daarin staat. Dezelfde getallen gelden op uw eigen computer, omdat de client dit ook controleert. Een privésleutel die leesbaar is voor andere gebruikers zorgt ervoor dat ssh de sleutel direct weigert, en ditmaal is de foutmelding duidelijk:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/matt/.ssh/id_ed25519' are too open.

chmod 600 ~/.ssh/id_ed25519 lost dit op.

~/.ssh/config: stop met het typen van opties

Een ~/.ssh/config-bestand op uw eigen computer geeft elke server een korte naam en onthoudt de opties die u anders steeds opnieuw moet typen. Maak het aan met 600-rechten en voeg per server een Host-blok toe:

Host web1
    HostName 10.0.0.10
    User matt
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host db1
    HostName 10.0.0.11
    User matt
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Nu vervangt ssh web1 de ssh -p 22 matt@10.0.0.10, en dezelfde korte naam werkt in scp, rsync en git, omdat deze allemaal dit bestand lezen. HostName is het werkelijke adres, User bespaart u het typen van de accountnaam en IdentityFile legt vast welke sleutel moet worden aangeboden.

IdentitiesOnly yes verdient een toelichting, omdat het een verwarrende fout oplost. Wanneer uw agent meerdere sleutels bevat, biedt de client deze één voor één aan en telt de server elke aanbieding als een mislukte poging. Met voldoende geladen sleutels krijgt u Received disconnect: Too many authentication failures voordat de juiste sleutel ooit wordt geprobeerd. IdentitiesOnly yes zorgt ervoor dat de client alleen de sleutel aanbiedt die in IdentityFile is benoemd, waardoor de fout niet kan optreden.

Passphrases en ssh-agent

Een passphrase versleutelt het private key-bestand op de schijf. Zonder passphrase kan iedereen die het bestand kopieert dit direct gebruiken; met een passphrase is het gestolen bestand onbruikbaar totdat de passphrase is geraden. Voor een key op een laptop is dit precies de bescherming die u nodig heeft, omdat laptops worden gestolen en back-ups van laptops kunnen lekken.

De reden dat een passphrase in de praktijk geen moeite kost, is ssh-agent. De agent houdt uw ontsleutelde key in het geheugen, waardoor u de passphrase slechts eenmaal per inlogsessie hoeft in te voeren en elke volgende verbinding direct verloopt. De meeste desktop Linux-distributies en macOS voeren al automatisch een agent voor u uit. Laad uw key in de agent met:

ssh-add ~/.ssh/id_ed25519

ssh-add -l toont de keys die de agent op dit moment bevat. Een waarschuwing: agent forwarding (ssh -A) stelt de externe server in staat om uw agent te gebruiken voor verdere authenticatie terwijl u verbonden bent. Schakel dit daarom alleen in voor servers die u volledig vertrouwt en laat het standaard uitgeschakeld.

Roteren en intrekken: de procedure bij een verloren laptop

Het intrekken van een standaard SSH-sleutel is niet meer dan het verwijderen van de bijbehorende regel uit authorized_keys op elke server waar deze op staat. Er is geen certificaatautoriteit om in te lichten en er is geen vervaldatum om af te wachten. Zodra de regel is verwijderd, mislukken nieuwe aanmeldingen met die sleutel.

Voer deze procedure nu uit, terwijl er geen sprake is van een noodsituatie. Kies een server, open ~/.ssh/authorized_keys en zoek de sleutel op basis van het commentaar. Verwijder de regel met een teksteditor of filter deze eruit op basis van het commentaar:

grep -v ' laptop$' ~/.ssh/authorized_keys > ~/.ssh/authorized_keys.tmp
mv ~/.ssh/authorized_keys.tmp ~/.ssh/authorized_keys

Controleer vervolgens vanaf het apparaat dat u zojuist heeft ingetrokken of aanmelden nu mislukt, en vanaf een ander apparaat of aanmelden nog steeds werkt. Let op één detail: het verwijderen van een sleutel beëindigt geen sessies die al geopend zijn, omdat de sleutel alleen bij het aanmelden wordt gecontroleerd. Als u een gestolen apparaat intrekt, controleer dan ook who op de server en beëindig elke sessie die u niet herkent.

Rotatie is dezelfde handeling in een andere volgorde: genereer een nieuwe sleutel op het apparaat, installeer deze met ssh-copy-id, bevestig dat de nieuwe sleutel toegang geeft en verwijder daarna de oude regel. Doe dit wanneer een apparaat van eigenaar wisselt, wanneer een sleutel mogelijk is blootgesteld, of wanneer iemand het team verlaat. Dit handmatig uitvoeren op twee servers is prima; op twintig servers is het een taak voor automatisering, en het beheren van meerdere Linux-servers laat zien hoe u dezelfde authorized_keys-status naar een volledig serverpark pusht.

Wat u niet moet doen

• Deel niet één private key met al uw apparaten. Hierdoor is het onmogelijk om een enkel gestolen apparaat in te trekken zonder de key overal te moeten vervangen.

• Commit geen private key naar een git repository, zelfs niet naar een private repository. Geautomatiseerde scanners monitoren publieke repositories en proberen gelekte keys binnen enkele minuten na een push uit, en een repository die later publiek wordt gemaakt, lekt zijn volledige geschiedenis.

• Upload de private key van uw laptop niet naar een server zodat die server een andere server kan bereiken. Genereer een aparte key op de server zelf en autoriseer die key precies daar waar deze nodig is.

• Plak geen private key in een chat, e-mail of ticket. De public key, het .pub bestand, is de enige helft die ooit gedeeld mag worden.

Zodra uw key u betrouwbaar laat inloggen, zet dan de volgende stap en schakel wachtwoordauthenticatie uit, zodat het constant raden naar wachtwoorden op uw server geen kans van slagen heeft. De drop-in configuratie hiervoor vindt u in SSH hardening op een VPS.

FAQ

Hoe werken SSH-keys zonder dat er een wachtwoord wordt verstuurd?

De server bewaart uw publieke key in ~/.ssh/authorized_keys. Bij het inloggen verstuurt de server een challenge, uw client ondertekent deze challenge met de private key en de server verifieert de handtekening met de publieke key. De private key verlaat nooit uw apparaat, waardoor er tijdens het transport niets te onderscheppen valt en er niets herbruikbaars van de server te stelen is. Een gecompromitteerde server lekt alleen publieke keys, die nergens gebruikt kunnen worden om in te loggen.

Moet ik dezelfde SSH-key gebruiken voor al mijn servers?

Het is correct om één key voor meerdere servers te gebruiken, zolang die key op één enkel apparaat blijft staan. De regel is één key per apparaat, niet één per server: de publieke key van uw laptop plaatst u op elke server die de laptop nodig heeft, en uw desktop heeft een eigen key. Dit houdt het intrekken van toegang eenvoudig, omdat het verlies van een apparaat betekent dat u slechts één herkenbare regel van elke server hoeft te verwijderen, terwijl de andere apparaten blijven werken.

Welke rechten moeten de .ssh directory en authorized_keys hebben?

Stel 700 in op ~/.ssh en 600 op authorized_keys en op elke private key, met het account dat ze gebruikt als eigenaar. sshd draait standaard met StrictModes yes, dus een bestand of home-directory waar iemand anders dan u naar kan schrijven, zorgt ervoor dat uw key stilzwijgend wordt genegeerd. Het enige spoor hiervan is Authentication refused: bad ownership or modes in de auth-log of journal van de server.

Hoe verwijder ik een SSH-key van een server?

Verwijder de regel van de key uit ~/.ssh/authorized_keys in het account waarvoor deze geautoriseerd was. Zoek de juiste regel op basis van het commentaar, het label dat achter de key-data staat. Nieuwe inlogpogingen met die key falen direct, maar sessies die al openstaan blijven actief. Beëindig daarom ook elke actieve sessie voor dat apparaat als het gestolen is. Herhaal dit op elke server waar de key naartoe is gekopieerd.

Heb ik een passphrase nodig voor mijn SSH-key?

Voor een key op een laptop of desktop: ja. De passphrase versleutelt het key-bestand, zodat een gestolen of gelekte kopie op zichzelf waardeloos is. Dankzij ssh-agent hoeft u deze slechts één keer per sessie in te voeren in plaats van bij elke verbinding. Keys die worden gebruikt door onbeheerde automatisering op een server hebben meestal geen passphrase, omdat er geen mens aanwezig is om deze in te voeren; beveilig deze keys door de rechten van het doelaccount te beperken.