Linux commando: ssh

1. De basis

De taak van ssh is je te verbinden met een andere computer over een onbetrouwbaar netwerk, en die verbinding veilig te maken. Je typt een regel, en een moment later hangt je toetsenbord aan een machine ergens anders.

$ ssh Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken.

Er zijn twee programma's bij betrokken. Aan jouw kant is ssh de client. Aan de andere kant is een achtergronddienst genaamd sshd (de SSH-daemon) de server. De client verbindt standaard met de server op TCP-poort 22, en de twee spreken af hoe ze praten voordat er ook maar een teken van je sessie over de lijn gaat.

In die openingshanddruk doet ssh drie losse dingen, en het helpt om ze in je hoofd uit elkaar te houden:

• Het controleert de server. De server bewijst dat hij een prive hostsleutel bezit, zodat je weet dat je de echte machine bereikt hebt en niet een bedrieger die ertussen zit.
• Het controleert jou. Je bewijst wie je bent met een sleutel of een wachtwoord, zodat de server weet welk account hij moet openen.
• Het versleutelt alles. Vanaf de handdruk is elke toetsaanslag en elke byte uitvoer versleuteld en op integriteit gecontroleerd.

Wat ssh bijzonder maakt, is dat het geen inlogprogramma bleef. Omdat het elke stroom bytes veilig kan dragen, zijn er andere programma's bovenop gebouwd. scp en sftp kopieren er bestanden mee. rsync gebruikt het als standaardtransport. git push over een ssh://-URL is een SSH-sessie. Ansible configureert er hele vloten servers mee. Leer ssh goed en je verbetert stilletjes al die gereedschappen tegelijk.

Het commando dat een machine op afstand in een lokale verandert. Achter een simpele inlogprompt zitten hostsleutels, sleutelparen, een agent, een configuratiebestand en een tunnelmachine waar de meeste gebruikers nooit aankomen.

Dit artikel begint bij je allereerste verbinding en bouwt op naar sleutels, het configuratiebestand, port forwarding, jump hosts, verbindingen delen en het dichttimmeren van de server. Aan het einde kun je een ssh-commando lezen dat iemand anders schreef en precies weten wat het doet.

Het juiste denkmodel: ssh is geen "terminalprogramma op afstand". Het is een versleutelde tunnel tussen twee machines, en een terminalsessie is alleen het meest voorkomende dat je erdoorheen duwt. Zodra je de tunnel ziet, houden port forwarding en jump hosts op trucjes te lijken en worden ze vanzelfsprekend.

3. Een korte geschiedenis

Anders dan ls of cat, die teruggaan tot de eerste dagen van Unix, is SSH een antwoord op een specifiek probleem op een specifiek moment. In 1995 ontdekte Tatu Ylönen, onderzoeker aan de Technische Universiteit Helsinki in Finland, een wachtwoord-afluisteraanval op zijn universiteitsnetwerk. Iemand ving de leesbare wachtwoorden op die telnet en rlogin zo gul weggaven. Hij schreef SSH als oplossing en bracht het in juli van dat jaar uit als freeware. Eind 1995 had het ongeveer 20.000 gebruikers in vijftig landen.

Succes bracht een bedrijf, en het bedrijf bracht licenties. Latere versies van het oorspronkelijke SSH werden commercieel en steeds beperkender. In 1999 nam het OpenBSD-team de laatste vrij gelicentieerde code, versie 1.2.12, maakte die schoon en bracht OpenSSH uit. Het werd meegeleverd met OpenBSD 2.6 op 1 december 1999. Vrijwel meteen begon een aparte portable-tak zodat dezelfde code op Linux en andere Unix-systemen kon draaien, en dat is de versie die vrijwel iedereen vandaag draait.

Je ziet beide feiten terug in de versieregel op elke Linux-machine:

$ ssh -V
OpenSSH_9.6p1 Ubuntu-3ubuntu13.18, OpenSSL 3.0.13 30 Jan 2024

De p1 staat voor portable, release 1. Alles na de komma is wat je distributie er bovenop heeft gezet.

Ondertussen werd het protocol zelf herschreven. Het oorspronkelijke SSH-1-protocol had ontwerpzwaktes, en een herontworpen SSH-2 verving het. De IETF publiceerde SSH-2 in januari 2006 als standaard, verspreid over RFC 4251 tot en met RFC 4254. SSH-1 is al lang dood en modern OpenSSH kan het helemaal niet meer spreken.

Die laatste rij verdient een tweede blik. De mensen die vandaag versleuteld verkeer opvangen in de hoop het te ontsleutelen zodra er quantumcomputers zijn, vormen al een echt dreigingsmodel. SSH is stilletjes overgestapt op sleuteluitwisseling die daartegen bestand is, en op OpenSSH 9.6 kun je het zien gebeuren:

$ ssh -v server.example
...
debug1: kex: algorithm: Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken.
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken. MAC: <implicit> compression: none

Je hebt er niets voor hoeven vragen, en dat hoefde ook niet. ssh bijgewerkt houden is het grootste deel van het beveiligingswerk.

5. Gemiddelde toepassingen

5.1 Sleutels in plaats van wachtwoorden

Bij elke verbinding een wachtwoord typen is traag, en erger nog, een wachtwoord kan geraden, gephisht of bruut geforceerd worden door de eindeloze robots die de hele dag poort 22 scannen. Authenticatie met een publieke sleutel lost beide problemen tegelijk op.

Je maakt een sleutelpaar aan: een privesleutel die je machine nooit verlaat, en een publieke sleutel die je vrij mag uitdelen. De server bewaart een kopie van de publieke sleutel. Als je verbindt, stuurt de server een uitdaging, je client ondertekent die met de privesleutel, en de server verifieert de handtekening met de publieke sleutel. Je geheim gaat nooit over de lijn, geen enkele keer.

$ ssh-keygen -t ed25519 -C "peter@laptop"
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/peter/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/peter/.ssh/id_ed25519
Your public key has been saved in /home/peter/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:nDjQm9DsoviIQK4am/qOpuskiuvJ1RY4lRpJgs+iyxY peter@laptop
The key's randomart image is:
+--[ED25519 256]--+
|.. .             |
|. o .+.          |
| o ooo+          |
|. o =+ = .       |
|.o +..* S        |
|+E .o...         |
|*+o. o           |
|@@o .            |
|^X+              |
+----[SHA256]-----+

Dat plaatje aan het einde is de randomart: een visuele tekening van dezelfde vingerafdruk. Het idee is dat mensen een veranderd plaatje sneller zien dan een veranderde reeks base64. Bijna niemand gebruikt het, en je kunt het rustig negeren.

Drie vlaggen doen er hier toe. -t (kort voor type) kiest het algoritme, -C (kort voor comment, opmerking) voegt een label toe zodat je je sleutels later uit elkaar houdt, en -f (kort voor file, bestand) zet de bestandsnaam als je de standaard niet wilt.

Op OpenSSH 9.5 en nieuwer kun je -t helemaal weglaten, omdat Ed25519 nu de standaard is. Het is voor bijna iedereen de juiste keuze: modern, snel en kort genoeg om op een regel te passen.

Kijk eens naar wat je daadwerkelijk krijgt. De publieke sleutel is een leesbare regel, en de privesleutel is een versleuteld blok dat je nooit opent:

$ cat ~/.ssh/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDA3N37toeUWk+bfwHUdgC64txzH0aqdogl9qkha0mme peter@laptop

$ head -2 ~/.ssh/id_ed25519
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW

De publieke regel heeft drie velden: het sleuteltype, de sleutel zelf in base64, en jouw opmerking. Die regel delen is veilig. Het bestand zonder .pub is het bestand dat je machine nooit mag verlaten, nooit in een chat geplakt mag worden en nooit in git terecht mag komen.

Zet altijd een wachtwoordzin. Een privesleutelbestand zonder wachtwoordzin is een inloggegeven in leesbare vorm: wie dat ene bestand kopieert, bezit elke server die het opent. Met een wachtwoordzin is het bestand op schijf versleuteld, en is een gestolen laptop een ongemak in plaats van een inbraak. Paragraaf 5.4 haalt de dagelijkse kosten van het typen weg.

Heb je al een sleutel zonder wachtwoordzin, dan hoef je niet opnieuw te beginnen. De vlag -p (kort voor passphrase, wachtwoordzin) wijzigt de wachtwoordzin van een bestaande sleutel en laat de sleutel zelf ongemoeid, dus er hoeft op geen enkele server iets bijgewerkt te worden:

$ ssh-keygen -p -f ~/.ssh/id_ed25519
Key has comment 'peter@laptop'
Enter new passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved with the new passphrase.

5.2 Je sleutel op de server krijgen

De server bewaart je publieke sleutels in ~/.ssh/authorized_keys, een per regel. Je kunt de regel met de hand toevoegen, maar er is gereedschap dat het correct doet, inclusief het aanmaken van de map met de juiste rechten:

$ ssh-copy-id Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken.
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/peter/.ssh/id_ed25519.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken.'"
and check to make sure that only the key(s) you wanted were added.

Het logt een laatste keer in met je wachtwoord en voegt de sleutel toe. Gebruik -i om een specifieke sleutel te kiezen en -n voor een proefdraai die laat zien wat het zou doen:

$ ssh-copy-id -n -i ~/.ssh/id_ed25519.pub Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken.
/usr/bin/ssh-copy-id: WARNING: All keys were skipped because they already exist on the remote system.

Rechten doen er meer toe dan beginners verwachten, en ssh weigert bewust te werken als ze verkeerd staan. Beide kanten controleren:

~/.ssh                 700   (drwx------)
~/.ssh/id_ed25519      600   (-rw-------)   private key
~/.ssh/id_ed25519.pub  644   (-rw-r--r--)   public key
~/.ssh/authorized_keys 600   (-rw-------)   on the server

Zet de privesleutel verkeerd en je krijgt een van de luidste foutmeldingen in Unix:

$ ssh -i ~/.ssh/id_ed25519 Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/peter/.ssh/id_ed25519' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.

De oplossing is een commando: chmod 600 ~/.ssh/id_ed25519. Dit is ook de meest voorkomende reden dat een sleutel die "gisteren nog werkte" ermee ophoudt nadat bestanden met de verkeerde vlaggen zijn rondgekopieerd.

5.3 Controleren of het gewerkt heeft

Voordat je ergens wachtwoorden uitzet, bevestig je in de logs van de server zelf dat de sleutel gebruikt is. Op de server:

$ sudo journalctl -u ssh --since "10 min ago" | tail -3
Accepted publickey for peter from 203.0.113.55 port 50962 ssh2: ED25519 SHA256:nDjQm9DsoviIQK4am/qOpuskiuvJ1RY4lRpJgs+iyxY

Het woord waar je op let is publickey. Staat er password, dan wordt je sleutel nog niet gebruikt en sluit je jezelf buiten als je wachtwoorden uitzet.

De naam van de dienst verschilt per distributiefamilie, wat mensen betrapt die met beide werken. Debian en Ubuntu noemen de unit ssh; Red Hat, Fedora en SUSE noemen hem sshd. Levert de ene naam niets op, probeer dan de andere:

$ systemctl status ssh      # Debian, Ubuntu
$ systemctl status sshd     # RHEL, Fedora, SUSE

Deze logs zijn meer waard dan een eenmalige controle. Ze leggen mislukte pogingen, onbekende gebruikersnamen en bron-IP-adressen vast, dus het is de eerste plek om te kijken als je wilt weten of iemand anders aan de deur heeft gerammeld.

5.4 De agent: je wachtwoordzin een keer typen

Een wachtwoordzin op je sleutel is alleen te doen als je hem een keer per dag typt in plaats van bij elke verbinding. Dat is het werk van ssh-agent, een klein achtergrondprogramma dat je ontsleutelde privesleutels in het geheugen houdt en op verzoek uitdagingen ondertekent. Het geeft de sleutel zelf nooit aan iets anders.

$ ssh-add ~/.ssh/id_ed25519
Enter passphrase for /home/peter/.ssh/id_ed25519:
Identity added: /home/peter/.ssh/id_ed25519 (peter@laptop)

$ ssh-add -l
256 SHA256:nDjQm9DsoviIQK4am/qOpuskiuvJ1RY4lRpJgs+iyxY peter@laptop (ED25519)

De vlag -l (kort voor list, lijst) laat zien wat de agent op dit moment heeft. Op een Linux-desktop wordt er meestal bij het inloggen al een agent voor je gestart, en je desktop-sleutelring ontgrendelt de sleutel misschien automatisch. Op een server of in een kale shell moet je er soms zelf een starten:

$ eval "$(ssh-agent -s)"
Agent pid 74960

Twee opties maken de agent prettiger in het gebruik. ssh-add -t (kort voor time, tijd) stelt een levensduur in, zodat de sleutel na een tijdje weer vergeten wordt, en AddKeysToAgent yes in je config laadt een sleutel in de agent zodra je hem voor het eerst gebruikt, zodat je ssh-add nooit meer met de hand draait:

$ ssh-add -t 8h ~/.ssh/id_ed25519    # forget it after eight hours

5.5 Het configuratiebestand dat alles verandert

Als je maar een ding uit dit artikel meeneemt naast sleutels, laat het dan ~/.ssh/config zijn. Het verandert lange, onthoudbare commando's in korte namen, en het is waar ervaren beheerders hun hele serverlijst bewaren.

Host web
    HostName web01.example.com
    User peter
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host *.internal
    User admin
    ServerAliveInterval 60

Host *
    AddKeysToAgent yes
    HashKnownHosts yes

Daarmee wordt dit:

$ ssh -p 2222 -i ~/.ssh/id_ed25519 Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken.

dit:

$ ssh web

De alias werkt overal, niet alleen in ssh: scp file web:/tmp/ en rsync -a site/ web:/var/www/ lezen hetzelfde bestand.

Een regel beheerst het hele bestand, en die verrast mensen: de eerste gevonden waarde voor elke instelling wint. Latere blokken kunnen een eerdere niet overschrijven. Dat is het tegenovergestelde van de meeste configuratieformaten, en het betekent dat specifieke Host-blokken bovenaan horen en het vangnet Host * onderaan.

Als je niet zeker weet wat ssh echt gaat doen, vraag het dan. De vlag -G drukt de volledig uitgewerkte configuratie voor een bestemming af zonder te verbinden:

$ ssh -G web | grep -E '^(hostname|user|port|identityfile)'
user peter
hostname web01.example.com
port 2222
identityfile ~/.ssh/id_ed25519

Dit ene commando beantwoordt de meeste "waarom verbindt hij als de verkeerde gebruiker?"-vragen in seconden.

5.6 Leven met known_hosts

Elke host die je accepteert belandt in ~/.ssh/known_hosts. Op Debian en Ubuntu worden de regels standaard gehasht, omdat /etc/ssh/ssh_config met HashKnownHosts yes wordt geleverd, dus het bestand ziet er zo uit in plaats van je servers leesbaar op te sommen:

$ head -1 ~/.ssh/known_hosts
|1|2UYDkyiaFpx+aPALlarpS9sQdVI=|KpOmbFYFEeDy0di64KcmzAaRymA= ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA...

Dat hashen is een bewuste verdediging: als iemand je laptop of je backups steelt, krijgt hij er niet ook een keurige lijst van elke server die je beheert bij. De keerzijde is dat je het bestand niet kunt lezen, dus je hebt ssh-keygen nodig om ermee te werken. Gebruik -F (kort voor find, zoeken) om een host op te zoeken en -R (kort voor remove, verwijderen) om hem weg te halen:

$ ssh-keygen -F server.example      # is this host known?
$ ssh-keygen -R server.example      # forget it

Vroeg of laat kom je de alarmerende versie hiervan tegen. Installeer een server opnieuw, of verhuis een domein naar een andere machine, en de hostsleutel verandert:

$ ssh Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:pWQKB1gfFxQ8fTJ9KiwFIFmT4g71fILH0jZEHn3mOII.
Offending ED25519 key in /home/peter/.ssh/known_hosts:2
  remove with:
  ssh-keygen -f '/home/peter/.ssh/known_hosts' -R 'server.example'
Host key verification failed.

ssh geeft je zelfs het exacte commando om de waarschuwing te laten verdwijnen, en precies daarom wordt de waarschuwing genegeerd. Sta eerst even stil. Als je die server een uur geleden opnieuw hebt geinstalleerd, is de verandering verwacht en mag je de regel opruimen. Als er aan jouw kant niets veranderd is, is dit de ene waarschuwing in heel Linux die echt betekent "misschien zit er iemand tussen", en dan is de juiste reactie om uit te zoeken waarom, voordat je nog iets typt.

7. Onder de motorkap: wat de versleuteling echt doet

Je kunt SSH jarenlang gebruiken zonder deze doos te openen, en alles hierboven werkt of je deze paragraaf nu leest of niet. Maar een verrassend aantal misverstanden verdwijnt zodra je weet wat er echt gebeurt, dus twintig minuten zijn het waard.

7.1 Drie soorten sleutels, en waarom mensen ze door elkaar halen

Het woord sleutel wordt in SSH voor drie totaal verschillende dingen gebruikt. Bijna elk verward gesprek over SSH-beveiliging komt voort uit het door elkaar halen daarvan.

De eerste twee leven lang en jij beheert ze. De derde soort wordt voor elke verbinding opnieuw gemaakt en je ziet hem nooit. Als iemand "SSH-sleutels" zegt, bedoelt hij bijna altijd de tweede soort, maar de waarschuwing in paragraaf 5.6 gaat over de eerste soort, en precies daarom verwart die waarschuwing mensen.

7.2 De handdruk, stap voor stap

Dit is de volgorde van gebeurtenissen als je ssh Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken. typt:

1. De client zoekt de hostnaam op en opent een gewone TCP-verbinding naar poort 22.
2. Beide kanten kondigen hun versieregels en hun lijsten met ondersteunde algoritmes aan.
3. Ze spreken af welke algoritmes ze gebruiken: een voor de sleuteluitwisseling, een voor de hostsleutel, een cipher en een integriteitscontrole. De winnaar is de eerste regel op de voorkeurslijst van de client die de server ook ondersteunt, en daarom verbetert een bijgewerkte client de verbinding zelfs naar een oudere server.
4. Ze draaien de sleuteluitwisseling, die gedeelde sessiesleutels oplevert zonder dat een van beide kanten ze ooit over de lijn stuurt.
5. De server ondertekent een deel van die uitwisseling met zijn hostsleutel en bewijst daarmee zijn identiteit. Je client controleert de handtekening tegen known_hosts.
6. De versleuteling gaat aan. Alles vanaf hier is beschermd.
7. Pas nu authenticeer jij, binnen het versleutelde kanaal.
8. De sessie start en de server draait je shell of je commando.

Stap 7 is degene om te onthouden. Je inloggegevens gaan pas nadat de versleuteling draait over de lijn, en daarom ligt zelfs een gewoon wachtwoord over SSH niet open op het netwerk, en daarom heeft SSH telnet zo volledig vervangen. Het verklaart ook de volgorde van de -v-uitvoer: eerst het gepraat over de sleuteluitwisseling, daarna de authenticatiepogingen.

Je ziet het onderhandelde resultaat bij elke verbinding:

$ ssh -v server.example 2>&1 | grep -E 'kex:|Server host key'
debug1: kex: algorithm: Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken.
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken. MAC: <implicit> compression: none
debug1: Server host key: ssh-ed25519 SHA256:Cbs69zP2QMpFcfrRMSlg3fsDbEpOD+MH2FANbuWy5J8

En je kunt je client vragen wat hij uberhaupt wil onderhandelen. De vlag -Q (kort voor query, opvragen) somt de algoritmes op die jouw build ondersteunt:

$ ssh -Q kex        # key exchange methods
$ ssh -Q key        # key and certificate types
$ ssh -Q cipher     # symmetric ciphers

Zo controleer je een compliance-eis of bevestig je dat een oud algoritme echt weg is, in plaats van het te gokken uit een blogbericht.

7.3 Forward secrecy: waarom een gestolen hostsleutel het verleden niet opent

Merk op dat de sessiesleutels in stap 4 vers gemaakt worden en nooit opgeslagen. Dat geeft SSH een eigenschap die forward secrecy heet, en die is sterker dan de meeste mensen aannemen.

Stel dat een aanvaller je versleutelde SSH-verkeer vandaag opneemt en bewaart. Jaren later breekt hij in op de server en steelt hij de prive hostsleutel. Hij kan de opgenomen sessies dan nog steeds niet lezen. De hostsleutel ondertekende alleen de handdruk, hij versleutelde de gegevens nooit, en de sleutels die dat wel deden zijn weggegooid op het moment dat je uitlogde.

De hostsleutel bewijst met wie je gepraat hebt. Hij beschermt niet wat je gezegd hebt. Dat werk hoort bij sessiesleutels die niet meer bestaan, en daarom is SSH-verkeer opvangen om later te ontsleutelen een slechte investering.

Dit is ook de reden dat de post-quantum sleuteluitwisseling uit paragraaf 3 zo belangrijk is. Forward secrecy houdt stand zolang de sleuteluitwisseling zelf later niet gebroken kan worden, dus die stap naar een quantumbestendig algoritme verhuizen beschermt gesprekken die je vandaag voert.

7.4 Certificaten: sleutels die vanzelf verlopen

Alles tot nu toe kopieert publieke sleutels naar authorized_keys, een bestand per gebruiker per server. Met vijf servers gaat dat prima. Met tweehonderd servers en dertig engineers wordt het een archiefprobleem, en het lastige is niet toegang geven maar toegang weghalen als iemand vertrekt.

OpenSSH lost dit op met certificaten. Je maakt een sleutel voor een certificaatautoriteit aan, en servers krijgen te horen dat ze die moeten vertrouwen. De CA ondertekent daarna gebruikerssleutels, en een ondertekende sleutel draagt een identiteit, een lijst met principals en een vervaldatum.

$ ssh-keygen -t ed25519 -f user_ca -C "user CA"          # once, kept very safe

$ ssh-keygen -s user_ca -I "peter@laptop" -n peter -V +1h ~/.ssh/id_ed25519.pub
Signed user key id_ed25519-cert.pub: id "peter@laptop" serial 0 for peter valid from 2026-08-11T14:04:00 to 2026-08-11T15:05:38

De vlaggen lezen als een zin: -s (kort voor sign, ondertekenen) kiest de CA-sleutel, -I (kort voor identity, identiteit) labelt voor wie dit is in de logs, -n somt de gebruikersnamen op waarmee het certificaat mag inloggen, en -V (kort voor validity, geldigheid) zet de levensduur. Je kunt het resultaat altijd bekijken:

$ ssh-keygen -Lf ~/.ssh/id_ed25519-cert.pub
        Type: Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken. user certificate
        Signing CA: ED25519 SHA256:f0JisVLECAQaZ8Zvusfs/hcR2RSfhKN3P0sHDRiCmFc
        Key ID: "peter@laptop"
        Valid: from 2026-08-11T14:04:00 to 2026-08-11T15:05:38
        Principals:
                peter
        Extensions:
                permit-pty
                permit-port-forwarding
                ...

Op de server vervangt een regel in sshd_config het hele archiefsysteem:

TrustedUserCAKeys /etc/ssh/user_ca.pub

Dat is de hele opzet. Daarmee slaagt een login zelfs als het bestand authorized_keys van de gebruiker helemaal leeg is, en de serverlog legt vast welk certificaat gebruikt is en welke CA ervoor instond:

Accepted publickey for peter from 203.0.113.55 port 52318 ssh2: ED25519-CERT SHA256:cSoLJ2nLw74r... ID peter@laptop (serial 0) CA ED25519 SHA256:f0JisVLECAQaZ8Zvusfs/hcR2RSfhKN3P0sHDRiCmFc

En als het uur om is, stopt de sleutel overal tegelijk met werken, zonder opruimwerk om te vergeten:

$ ssh Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken.
Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken.: Permission denied (publickey).

# in the server log:
Certificate invalid: expired

Hetzelfde idee werkt de andere kant op. Een hostcertificaat dat ondertekend is door een CA die je clients vertrouwen, haalt de vraag over vertrouwen bij eerste gebruik uit paragraaf 4.2 helemaal weg: nieuwe servers worden meteen herkend, en niemand hoeft vingerafdrukken met de hand te vergelijken. De keerzijde is echt. De prive CA-sleutel wordt het waardevolste geheim dat je hebt, want hij kan voor iedereen instaan, dus hij hoort offline of in hardware en niet op een buildserver.

9. Best practices

• Gebruik Ed25519-sleutels met een wachtwoordzin, en een agent. Een keer ssh-keygen -t ed25519, een keer per dag ssh-add, en je krijgt betere beveiliging en minder typwerk tegelijk.
• Zet wachtwoordauthenticatie uit zodra sleutels werken. Controleer eerst de serverlog op Accepted publickey, houd een tweede sessie open, en zet dan pas PasswordAuthentication no.
• Zet alles in ~/.ssh/config. Hosts, gebruikers, poorten, sleutels, jump hosts, keepalives. Onthoud dat de eerste passende waarde wint, dus specifieke blokken staan bovenaan.
• Deel of kopieer nooit een privesleutel. Een sleutelpaar per machine waarop je typt. Raak je een laptop kwijt, dan haal je een publieke sleutel uit authorized_keys in plaats van alles te vervangen.
• Lees de waarschuwing over de hostsleutel voordat je hem opruimt. Verwacht na een herinstallatie, alarmerend op elk ander moment. Dit is de ene waarschuwing die tien minuten van je aandacht waard is.
• Beperk geautomatiseerde sleutels. Elke sleutel die door een script of CI-systeem gebruikt wordt, verdient restrict, een afgedwongen command= en een from=-adreslijst.
• Kies ProxyJump boven agent forwarding. Hetzelfde gemak, geen van de risico's.
• Vraag wat een account kan bereiken, niet alleen wat het kan typen. SSH-toegang is netwerktoegang. Zet AllowTcpForwarding no voor accounts die geen tunnels nodig hebben.
• Wordt het beheer van sleutelbestanden een archiefprobleem, stap dan over op certificaten. Een vertrouwde CA, korte geldigheidsduur, en toegang die vanzelf eindigt in plaats van te wachten tot iemand eraan denkt.
• Zet verbindingen delen aan. ControlMaster auto met ControlPersist laat elk SSH-gereedschap dat je hebt sneller aanvoelen, voor vier regels config.
• Houd OpenSSH bijgewerkt. De standaardwaarden voor ciphers en sleuteluitwisseling worden bij elke release beter, en je krijgt die verbeteringen gratis.
• Grijp naar de documentatie. De handleidingen zijn uitstekend en behandelen veel meer dan welk artikel dan ook kan.

$ man ssh              # the client
$ man ssh_config       # every client option, including the config file
$ man sshd_config      # every server option
$ man ssh-keygen       # keys, fingerprints, known_hosts, certificates
$ ssh -G server        # what ssh will actually do for this host

11. Samenvatting

Het commando ssh lijkt een manier om een terminal op een andere machine te krijgen, en dat is het ook. Het is daarnaast de versleutelde tunnel waar het meeste moderne serverbeheer doorheen loopt.

• ssh betekent Secure SHell. Het verving telnet, rlogin en rsh, die wachtwoorden in leesbare tekst stuurden, en het gebruikt poort 22 omdat die tussen ftp en telnet lag.
• Tatu Ylönen schreef het in 1995 na een wachtwoord-afluisteraanval in Finland. Het OpenBSD-team forkte de laatste vrije versie in 1999 tot OpenSSH, en het SSH-2-protocol werd in 2006 een IETF-standaard.
• Elke verbinding doet drie dingen: de hostsleutel van de server verifieren, jou authenticeren, en alles versleutelen. De vraag bij de eerste verbinding en known_hosts zijn hoe het eerste werkt.
• Authenticatie met een publieke sleutel verslaat wachtwoorden: ssh-keygen -t ed25519, ssh-copy-id, daarna PasswordAuthentication no op de server. Zet altijd een wachtwoordzin en laat ssh-agent de sleutel vasthouden.
• ~/.ssh/config verandert lange commando's in korte aliassen en wordt ook door scp, rsync en git gelezen. De eerste passende waarde wint, dus specifieke hosts staan bovenaan.
• -L haalt een poort op afstand naar je toe, -R deelt een lokale poort uit, en -D verandert ssh in een SOCKS-proxy voor een heel prive netwerk.
• -J (ProxyJump) bereikt machines achter een bastion, end-to-end versleuteld, en is de veilige vervanger van agent forwarding.
• ControlMaster met ControlPersist hergebruikt een verbinding voor veel sessies en maakt elk SSH-gereedschap merkbaar sneller.
• Een tilde aan het begin van een regel praat met je lokale client, niet met de server: ~. doodt een bevroren sessie, ~? somt de rest op, en ~C voegt een port forward toe zonder opnieuw te verbinden zodra je EnableEscapeCommandline yes zet.
• In authorized_keys beperken restrict, command= en from= een sleutel tot precies een taak vanaf precies een plek.
• Drie verschillende dingen heten een sleutel: de hostsleutel van de server, jouw gebruikerssleutel, en de wegwerp-sessiesleutels die het echte versleutelen doen. Omdat de sessiesleutels weggegooid worden, kan een later gestolen hostsleutel het verkeer van vandaag niet ontsleutelen.
• SSH-certificaten vervangen het overal kopieren van publieke sleutels: een CA ondertekent een sleutel met een identiteit en een vervaldatum, servers vertrouwen de CA via TrustedUserCAKeys, en toegang eindigt vanzelf.
• Iemand SSH-toegang geven geeft hem netwerktoegang tot alles wat de server kan bereiken. AllowTcpForwarding no en permitopen zetten daar grenzen aan.
• Op de server doen PasswordAuthentication no, PermitRootLogin no en AllowUsers het meeste werk. Test met sshd -t en houd een tweede sessie open.
• Twijfel je, draai dan ssh -v om te zien wat er gebeurt, of ssh -G host om te zien wat er zou gebeuren.

Dit is het overzicht dat je het beste kunt bewaren:

ssh user@host                      log in
ssh -p 2222 user@host              non-standard port
ssh user@host 'uptime'             run one command and exit
ssh -v user@host                   show what is going wrong
ssh -G host                        show the resolved config, do not connect

ssh-keygen -t ed25519 -C "me@laptop"   create a key pair
ssh-copy-id user@host                  install the public key
ssh-add -t 8h ~/.ssh/id_ed25519        load it into the agent for 8 hours
ssh-keygen -lf ~/.ssh/id_ed25519.pub   show a key fingerprint
ssh-keygen -p -f ~/.ssh/id_ed25519     add or change the passphrase
ssh-keygen -R host                     forget a changed host key
ssh-keygen -s ca -I who -n user -V +8h key.pub   sign a short-lived certificate
ssh-keygen -Lf key-cert.pub            inspect a certificate

ssh -f -N -L 3307:127.0.0.1:3306 host  remote database on your local port 3307
ssh -f -N -R 9097:127.0.0.1:3000 host  your local app on the server's port 9097
ssh -f -N -D 9098 host                 SOCKS proxy through the server
ssh -J user@gateway user@internal      reach a host behind a bastion
ssh -O check host                      is a shared master connection running?

~.     disconnect a frozen session      (press Enter first)
~#     list the forwards on this connection
~?     list the escape sequences
~C     add a port forward mid-session   (needs EnableEscapeCommandline yes)

SSH is het ene commando waarbij een beetje extra kennis zich elke dag terugbetaalt: minder wachtwoorden, snellere deployments, en een server die ophoudt interessant te zijn voor de robots die hem scannen.