ssh sleutel

Je 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 je een Ed25519-sleutel genereert, installeert en gebruikt op een Linux-server, en waarom die aanpak beter is dan wat je 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 je 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 je eigen machine blijft en een public key die op de server komt te staan. Bij het inloggen bewijst je client met de private key dat hij bij de public key hoort. De server verifieert dat met de public key en laat je 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 je SSH-poort zinloos wordt: er valt niets te raden.

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

Een sleutelpaar genereren

Open een terminal op je client en typ:

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

Ed25519 is het algoritme dat je 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 je passphrase duurder. De `-C` is een commentaarveld, handig om later te zien welke key waarvoor dient.

Het commando vraagt waar je de key wilt opslaan. De standaardlocatie is `~/.ssh/id_ed25519`. Die kun je aanhouden, tenzij je al een key op die plek hebt — overschrijf die niet. Daarna vraagt het om een passphrase. Die kun je 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 noteer je ergens; later kun je ermee controleren of je 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 je als wilt inloggen. Dat kan handmatig, maar er is een commando dat het voor je doet:

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

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

Geen `ssh-copy-id` op je systeem? Dan plak je 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 kun je inloggen zonder wachtwoord:

ssh gebruiker@server.example.com

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

Heb je geen passphrase ingesteld, dan log je nu volledig zonder prompt in. Handig voor scripts, maar je private key ligt dan onversleuteld op schijf.

De passphrase niet elke keer typen

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

Start de agent en voeg je key toe:

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

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

Dit is ook wat je 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

Je 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 je die achterdeur.

Herstart daarna SSH:

sudo systemctl restart sshd

Voordat je de huidige sessie sluit: open een tweede terminal en test of je nog kunt inloggen met je key. Zit er een fout in je configuratie, dan sta je buiten en moet je via de console of een provider-panel weer binnen zien te komen. Die vergissing kost je een middag.

Verificatie

Controleer of alles werkt:

ssh -v gebruiker@server.example.com

In de output zoek je naar een regel als `Authenticated to server.example.com ([IP]:22)` en `Server accepts key`. Zie je `Permission denied (publickey)`, dan accepteert de server je key niet — check 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 je 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. Je kopieert de key naar de verkeerde account. Log in met de gebruikersnaam die je normaal gebruikt en herhaal het commando.

Je kunt niet meer inloggen na het uitschakelen van wachtwoordauth. De sshd-config bevat een fout of je 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 je 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 je nu hebt

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

Een SSH-sleutel is geen eenmalige setup. Als je machine wordt gestolen, moet je 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.