SSH keys beheren en gebruiken

Hoe SSH-keys werken

Een SSH-key bestaat uit een paar bestanden: een private key die op uw apparaat blijft staan en een public key die u kopieert naar elke server waarop u wilt inloggen. Bij een verbinding 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. Hierdoor wordt er geen geheim over het netwerk verzonden en heeft een gecompromitteerde server niets nuttigs te stelen. Daarom zijn keys veiliger dan wachtwoorden. Goed beheer van SSH-keys valt terug op vier gewoonten: één key per apparaat, de door sshd vereiste bestandsrechten, een ~/.ssh/config bestand om het typen van opties te voorkomen, en weten hoe u een key verwijdert op de dag dat een laptop wordt gestolen.

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

Een punt van terminologie voordat we beginnen, omdat dit fouten voorkomt. De public key is niet geheim. U kunt deze in een ticket plakken, per e-mail verzenden of publiceren, en niemand kan hiermee inloggen. De private key is het geheim. Iedereen die dat bestand kopieert, en de passphrase kent (indien aanwezig), wordt door uw servers beschouwd als u.

Een sleutel aanmaken: ed25519 is de juiste standaard

Voer dit uit op uw eigen computer, niet op de server:

ssh-keygen -t ed25519 -C "laptop"

-t ed25519 bepaalt het type sleutel. Ed25519 is de moderne standaard: de sleutels zijn kort, snel en worden ondersteund door elke OpenSSH-versie sinds 2014. Gebruik alleen ssh-keygen -t rsa -b 4096 als u verbinding moet maken met een oud apparaat dat ed25519 niet ondersteunt. -C "laptop" stelt een commentaar in. Het commentaar heeft geen cryptografische functie, maar het helpt u om deze sleutel over twee jaar te herkennen in het authorized_keys-bestand op de server. Gebruik daarom de naam van het apparaat waar de sleutel op staat.

ssh-keygen vraagt waar de sleutel moet worden opgeslagen. Accepteer de standaardwaarde, ~/.ssh/id_ed25519. Daarna wordt er gevraagd om een passphrase. Stel een passphrase in; de sectie over passphrases hieronder legt uit waarom dit dagelijks geen extra moeite kost. U krijgt twee bestanden: ~/.ssh/id_ed25519 is de private key en ~/.ssh/id_ed25519.pub is de public key. Bekijk de publieke helft:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

Het is één regel: het type sleutel, de sleutelinhoud en uw commentaar. Die regel wordt op uw servers geplaatst.

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

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

Dit model is schaalbaar, terwijl alternatieven op voorspelbare wijze falen. Eén sleutel per server betekent dat een laptop met twintig servers twintig private sleutels bevat; u verliest dan het overzicht. Eén gedeelde sleutel voor al uw apparaten is nog slechter: als de laptop wordt gestolen, kunt u de toegang van de laptop niet intrekken zonder ook de desktop uit te sluiten. Omdat beide apparaten dezelfde private sleutel gebruiken, moet u de sleutel overal vervangen en deze in één keer naar elk apparaat distribueren.

Met één sleutel per apparaat kost een verloren laptop u slechts één regel per server: verwijder de regel van de laptop uit authorized_keys en alle andere apparaten blijven werken. De commentaar die u instelt met -C zorgt ervoor dat die regel gemakkelijk te vinden is.

De regel achter dit model: een private sleutel wordt op een apparaat aangemaakt en vervalt samen met dat apparaat. Kopieer een private sleutel nooit naar een tweede machine en upload deze nooit naar een server. Wanneer een nieuw apparaat toegang nodig heeft, genereert u daar een nieuwe sleutel op.

Plaats de publieke sleutel op de server

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

ssh-copy-id matt@10.0.0.10

Deze methode logt in met de huidige methode, meestal een wachtwoord. De publieke sleutel wordt toegevoegd aan ~/.ssh/authorized_keys op de server. Indien nodig worden de map en het bestand met de juiste permissies aangemaakt. Test dit door een nieuwe SSH-sessie te openen: de server moet toegang verlenen zonder om het accountwachtwoord te vragen. Als uw sleutel een passphrase heeft, vraagt uw eigen machine hierom; deze prompt is lokaal en is niet het wachtwoord van de server.

Wanneer inloggen met een wachtwoord al is uitgeschakeld, kan ssh-copy-id niet inloggen. Voeg de regel dan handmatig toe. Log in via een werkende sessie of de webconsole van uw provider, en voer dit 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 echte publieke sleutel tussen de aanhalingstekens; gebruik de volledige regel uit id_ed25519.pub. authorized_keys bevat één publieke sleutel per regel; dit is de volledige toegangsdatabase. Een apparaat toevoegen betekent een regel toevoegen. Een apparaat intrekken betekent een regel verwijderen. Op een nieuwe server hoort deze stap in de eerste 10 minuten op een nieuwe VPS, direct voordat u inloggen met een wachtwoord uitschakelt.

De permissies die key login verhinderen

Dit is de meest voorkomende reden waarom key login mislukt. De fout wordt aan de client-zijde niet aangegeven. sshd draait standaard met StrictModes yes op Ubuntu 24.04. Dit betekent dat sshd een authorized_keys bestand weigert als andere gebruikers dit kunnen bewerken. Als het bestand, de ~/.ssh directory, of uw home directory beschrijfbaar is voor iemand anders dan u, negeert sshd uw key. De verbinding valt terug op een wachtwoord zonder foutmelding aan de client. (De OpenSSH-versie van Ubuntu staat slechts één uitzondering toe: een bestand dat beschrijfbaar is door uw eigen private group, waar niemand anders deel van uitmaakt. Vertrouw hier niet op; gebruik de onderstaande modes.) De reden hiervoor verschijnt alleen in het logbestand van de server:

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

Op een minimale image zonder rsyslog is er geen auth.log; 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 permissies en een controle van de ownership. Voer deze uit 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 directory, 600 op alles daarin. Dezelfde getallen zijn van toepassing op uw eigen computer, omdat de client dit ook controleert. Een private key die leesbaar is voor andere gebruikers zorgt ervoor dat ssh de key direct weigert. In dit geval wordt de fout wel aangegeven:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         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 typing options

Een ~/.ssh/config bestand op uw eigen computer geeft elke server een korte naam en onthoudt de opties die u herhaaldelijk invoert. Maak het bestand aan met 600 rechten en voeg voor elke 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 ssh -p 22 matt@10.0.0.10, en dezelfde korte naam werkt in scp, rsync en git, omdat deze allemaal dit bestand uitlezen. HostName is het werkelijke adres, User voorkomt dat u de gebruikersnaam moet typen, en IdentityFile bepaalt welke sleutel wordt aangeboden.

IdentitiesOnly yes verdient een aparte uitleg, omdat het een verwarrende fout herstelt. Wanneer uw agent meerdere sleutels bevat, biedt de client deze één voor één aan. De server telt elke aanbieding als een mislukte poging. Bij voldoende geladen sleutels krijgt u Received disconnect: Too many authentication failures voordat de juiste sleutel wordt geprobeerd. IdentitiesOnly yes zorgt ervoor dat de client alleen de sleutel aanbiedt die in IdentityFile staat vermeld, waardoor deze 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 het direct gebruiken. Met een passphrase is het gestolen bestand waardeloos totdat de passphrase is geraden. Voor een sleutel op een laptop is dit de gewenste bescherming, omdat laptops gestolen kunnen worden en backups kunnen lekken.

De reden dat een passphrase in de praktijk geen extra moeite kost, is ssh-agent. De agent bewaart de gedecrypteerde sleutel in het geheugen. Hierdoor voert u de passphrase slechts eenmaal per loginsessie in en zijn alle volgende verbindingen direct beschikbaar. De meeste desktop Linux-distributies en macOS draaien al een agent voor u. Laad uw sleutel in de agent met:

ssh-add ~/.ssh/id_ed25519

ssh-add -l toont de sleutels die de agent momenteel beheert. Let op: agent forwarding (ssh -A) stelt de remote 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 oefening voor een verloren laptop

Het intrekken van een gewone SSH-key is niets meer dan het verwijderen van de bijbehorende regel uit authorized_keys op elke server waar deze aanwezig is. Er is geen certificate authority die u moet informeren en er is geen vervaldatum waar u op moet wachten. Zodra de regel is verwijderd, mislukken nieuwe logins met die key.

Voer de oefening nu uit, terwijl er geen sprake is van een noodsituatie. Kies een server, open ~/.ssh/authorized_keys en zoek de key aan de hand van het commentaar. Verwijder de regel met een editor, 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

Bevestig vervolgens vanaf het zojuist ingetrokken apparaat dat de login mislukt, en vanaf een ander apparaat dat de login nog steeds werkt. Let op één detail: het verwijderen van een key sluit geen sessies die al geopend zijn, omdat de key alleen bij het inloggen 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 operatie in een andere volgorde: genereer een nieuwe key op het apparaat, installeer deze met ssh-copy-id, bevestig dat de nieuwe key kan inloggen, en verwijder vervolgens de oude regel. Voer dit uit wanneer een apparaat van eigenaar wisselt, wanneer een key mogelijk is blootgesteld, of wanneer iemand uit een team vertrekt. Dit handmatig op twee servers doen is geen probleem; op twintig servers is dit een taak voor automatisering. het beheren van meerdere Linux-servers laat zien hoe u dezelfde authorized_keys status naar een volledige vloot pusht.

Wat u niet moet doen

• Gebruik niet één private key voor al uw apparaten. Als een apparaat wordt gestolen, kunt u de sleutel niet intrekken zonder deze overal te vervangen.

• Commit geen private key naar een git repository, zelfs niet bij een private repository. Automatische scanners controleren publieke repositories en proberen gelekte sleutels binnen enkele minuten na een push. Als een repository later publiek wordt, lekt de volledige geschiedenis.

• Upload de private key van uw laptop niet naar een server om die server toegang te geven tot een andere server. Genereer een aparte key op de server zelf en autoriseer deze key alleen waar dat strikt noodzakelijk is.

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

Zodra uw key een betrouwbare login mogelijk maakt, is de volgende stap het uitschakelen van password authentication. Hiermee voorkomt u dat brute-force aanvallen op uw server slagen. De configuratie hiervoor vindt u in SSH hardening on a VPS.

FAQ

Hoe werken SSH-keys zonder een wachtwoord te verzenden?

De server bewaart uw publieke sleutel in ~/.ssh/authorized_keys. Bij het inloggen stuurt de server een challenge. Uw client ondertekent deze challenge met de private key. De server verifieert de handtekening met de publieke sleutel. De private key verlaat uw apparaat nooit. Hierdoor kan er niets worden onderschept tijdens het transport en kan er niets van de server worden gestolen. Een gehackte server lekt alleen publieke sleutels, die niet gebruikt kunnen worden om ergens anders in te loggen.

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

Het is correct om één sleutel voor meerdere servers te gebruiken, mits die sleutel op één enkel apparaat blijft staan. De regel is één sleutel per apparaat, niet één per server: de publieke sleutel van uw laptop gaat op elke server waar de laptop toegang toe nodig heeft, en uw desktop heeft een eigen sleutel. Dit maakt het intrekken van toegang (revocation) eenvoudig. Als u een apparaat verliest, hoeft u slechts één identificeerbare regel op elke server te verwijderen. 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. De bestanden moeten eigendom zijn van het account dat ze gebruikt. sshd draait standaard met StrictModes yes. Als een bestand of home directory beschrijfbaar is voor iemand anders dan u, negeert sshd uw sleutel stilzwijgend. Het enige spoor 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 sleutel uit ~/.ssh/authorized_keys van het account waarvoor deze was geautoriseerd. Zoek de juiste regel aan de hand van het commentaar, de tekst na de sleutelgegevens. Nieuwe inlogpogingen met die sleutel mislukken onmiddellijk. Lopende sessies blijven echter openstaan. Beëindig ook actieve sessies voor dat apparaat als het is gestolen. Herhaal dit op elke server waar de sleutel is gekopieerd.

Heb ik een passphrase nodig voor mijn SSH-key?

Voor een sleutel op een laptop of desktop: ja. De passphrase versleutelt het sleutelbestand. Een gestolen of gelekte kopie is daardoor op zichzelf nutteloos. ssh-agent betekent dat u deze één keer per sessie moet typen in plaats van bij elke verbinding. Sleutels die worden gebruikt voor unattended automation op een server hebben meestal geen passphrase, omdat er geen mens aanwezig is om deze in te voeren. Bescherm deze sleutels door de rechten van het doelaccount te beperken.