ssh-sleutel

Uw wachtwoord gaat over de kabel. Elke switch, elk apparaat op de route kan het lezen. SSH-sleutels lossen dat op met cryptografie, maar de stap van wachtwoord naar sleutel schrikt veel beheerders af — onterecht. Dit artikel legt uit hoe u een Ed25519-sleutel genereert, installeert en gebruikt op een Linux-server, en waarom die aanpak beter is dan wat u nu doet.

Vereisten

• Een Linux-client met OpenSSH 7.0 of nieuwer (check met `ssh -V`). Alles vanaf Ubuntu 16.04 of Debian 9 voldoet.
• Toegang tot een externe server via SSH met wachtwoord.
• `ssh-copy-id` aanwezig op uw client (standaard bij OpenSSH, apart pakket op sommige distro's).

Wat een SSH-sleutel doet

Een SSH-sleutel is een cryptografisch paar: een private key die op uw eigen machine blijft en een public key die op de server komt te staan. Bij het inloggen bewijst uw client met de private key dat hij bij de public key hoort. De server verifieert dat met de public key en laat u binnen — zonder wachtwoord.

Dat is geen detail. Het betekent dat er geen wachtwoord meer over het netwerk gaat dat onderschept kan worden. Het betekent ook dat een brute-force-aanval op uw SSH-poort zinloos wordt: er valt niets te raden.

De prijs van die veiligheid is dat uw private key het nieuwe aanvalsoppervlak wordt. Iemand die uw laptop buitmaakt en de key zonder passphrase aantreft, heeft toegang tot alles waar die key toegang toe geeft. Daarom hoort een passphrase op uw key — daarover later meer.

Een sleutelpaar genereren

Open een terminal op uw client en typ:

ssh-keygen -t ed25519 -a 100 -C "uw@email.nl"

Ed25519 is het algoritme dat u wilt. Het is sneller dan RSA, de sleutels zijn kleiner en de beveiliging is ruimer gedocumenteerd. De `-a 100` vertelt ssh-keygen om de key 100 keer door de KDF-functie te halen; dat maakt een brute-force op uw passphrase duurder. De `-C` is een commentaarveld, handig om later te zien welke key waarvoor dient.

Het commando vraagt waar u de key wilt opslaan. De standaardlocatie is `~/.ssh/id_ed25519`. Die kunt u aanhouden, tenzij u al een key op die plek hebt — overschrijf die niet. Daarna vraagt het om een passphrase. Die kunt u leeg laten, maar doe dat niet. Een key zonder passphrase is een tekstbestand dat, eenmaal gestolen, direct werkt.

De output eindigt met een vingerafdruk en een "randomart image". Die vingerafdruk noteert u ergens; later kunt u ermee controleren of u tegen de juiste server praat.

De public key installeren

De public key moet naar de server, in het bestand `~/.ssh/authorized_keys` van de gebruiker waar u als wilt inloggen. Dat kan handmatig, maar er is een commando dat het voor u doet:

ssh-copy-id -i ~/.ssh/id_ed25519.pub gebruiker@server.example.com

U moet nog één keer uw wachtwoord intoetsen, daarna kopieert `ssh-copy-id` de key naar de juiste plek en zet de permissies goed. Als uw server op een andere poort draait dan 22, voeg dan `-p ` toe aan het commando.

Geen `ssh-copy-id` op uw systeem? Dan plakt u de key handmatig. Toon de public key met:

cat ~/.ssh/id_ed25519.pub

Kopieer de volledige regel en voeg die op de server toe aan `~/.ssh/authorized_keys`. Maak die map aan als hij niet bestaat:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "de-gekopieerde-public-key" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

De permissies zijn geen formaliteit. OpenSSH weigert keys te gebruiken uit bestanden die leesbaar zijn voor anderen. Een `authorized_keys` met `chmod 644` werkt simpelweg niet.

Inloggen zonder wachtwoord

Nu kunt u inloggen zonder wachtwoord:

ssh gebruiker@server.example.com

U typt nu uw passphrase in plaats van uw wachtwoord. Dat lijkt op hetzelfde, maar is het niet: de passphrase verlaat uw machine niet. Die ontsleutelt alleen uw private key in het geheugen.

Hebt u geen passphrase ingesteld, dan logt u nu volledig zonder prompt in. Handig voor scripts, maar uw private key ligt dan onversleuteld op schijf.

De passphrase niet elke keer typen

Een passphrase die u bij elke verbinding moet intoetsen wordt snel irritant, zeker als u vaker per dag verbinding maakt. `ssh-agent` onthoudt de ontsleutelde key voor uw sessie.

Start de agent en voeg uw key toe:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

U typt uw passphrase één keer. Daarna gebruikt `ssh` de key uit de agent voor alle verbindingen, tot u de agent stopt of uitlogt. Op de meeste Linux-desktops draait er al een ssh-agent in uw sessie; check met `ssh-add -l` of er keys geladen zijn.

Dit is ook wat u wilt voor automatisering. Een cronjob die via rsync een backup maakt, kan niet interactief een passphrase intoetsen. Met de agent geladen werkt hij zonder prompt.

Wachtwoordauthenticatie uitschakelen

U hebt nu sleutelauthenticatie werkend. De volgende stap is wachtwoordlogin uitschakelen op de server, want zolang die aanstaat blijft brute-force een risico.

Op de server, bewerk `/etc/ssh/sshd_config` als root:

sudo nano /etc/ssh/sshd_config

Zet deze regels erin of pas ze aan:

PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no

De derde regel is belangrijk. Veel systemen gebruiken PAM voor "keyboard-interactive" authenticatie, en die omzeilt `PasswordAuthentication no` soms. Met `KbdInteractiveAuthentication no` sluit u die achterdeur.

Herstart daarna SSH:

sudo systemctl restart sshd

Voordat u de huidige sessie sluit: open een tweede terminal en test of u nog kunt inloggen met uw key. Zit er een fout in uw configuratie, dan staat u buitenspel en moet u via de console of een provider-panel weer binnen zien te geraken. Die vergissing kost u een namiddag.

Verificatie

Controleer of alles werkt:

ssh -v gebruiker@server.example.com

In de output zoekt u naar een regel als `Authenticated to server.example.com ([IP]:22)` en `Server accepts key`. Ziet u `Permission denied (publickey)`, dan accepteert de server uw key niet — controleer de permissies van `~/.ssh` en `authorized_keys` op de server.

Een tweede check: kijk op de server of er geen wachtwoordlogins meer binnenkomen:

sudo grep "Failed password" /var/log/auth.log | tail -20

Na het uitschakelen van wachtwoordauthenticatie zou die lijst leeg moeten blijven, afgezien van pogingen die al liepen.

Veelgemaakte fouten

De server accepteert de key niet. Controleer de permissies: `~/.ssh` moet `700` zijn, `authorized_keys` `600`. Check ook of u de public key hebt gekopieerd en niet de private — die laatste hoort nooit op een server te staan.

`ssh-copy-id` vraagt om een wachtwoord voor een andere gebruiker. U kopieert de key naar de verkeerde account. Log in met de gebruikersnaam die u normaal gebruikt en herhaal het commando.

U kunt niet meer inloggen na het uitschakelen van wachtwoordauth. De sshd-config bevat een fout of uw key staat niet goed op de server. Log via de console of een out-of-band-oplossing in, zet `PasswordAuthentication` terug op `yes`, herstart sshd en doorloop de stappen opnieuw.

Keys werken niet in een cronjob. Cron draait zonder uw ssh-agent. Gebruik geen key zonder passphrase voor dit doel; maak een aparte key per taak met een eigen passphrase en laad die in een agent die de cronjob kan bereiken, of gebruik een tool zoals `keychain` om de agent per sessie te starten.

Wat u nu hebt

U logt in zonder wachtwoord over het netwerk, uw server staat niet meer open voor brute-force en uw private key ligt versleuteld op uw eigen machine. Voor het geval u het zich afvroeg: ja, dit is ook de manier waarop u Git-over-SSH en rsync-backups veilig krijgt. Dezelfde key werkt daarvoor.

Een SSH-sleutel is geen eenmalige setup. Als uw machine wordt gestolen, moet u de public key van alle servers verwijderen en een nieuw paar genereren. Maar dat is een incident, geen dagelijkse zorg. De dagelijkse zorg — een wachtwoord dat elke keer over het netwerk gaat — is opgelost.