Wat is SSH en hoe werkt dit protocol?

Wat is SSH?

SSH (secure shell) is een protocol om in te loggen op een externe computer en daarop commando's uit te voeren via een versleutelde verbinding. Wat u typt wordt naar de externe machine verzonden, de uitvoer komt terug, en niemand die het netwerkverkeer tussentijds onderschept kan de inhoud lezen. Een gehuurde Linux-server heeft geen scherm of toetsenbord; SSH is daarom de manier waarop de machine wordt beheerd.

De naam verwijst naar twee zaken. SSH is het protocol, beschreven in RFC 4251 tot en met RFC 4254. OpenSSH is het programma dat dit protocol implementeert en is de software die op vrijwel elke Linux-server en laptop draait. Wanneer iemand spreekt over "SSH into the server", bedoelt diegene dat het clientprogramma ssh op de eigen machine communiceert met het serverprogramma sshd aan de andere kant.

Het probleem dat SSH moest vervangen

Remote login is veel ouder dan SSH. Telnet opende een onversleutelde TCP-verbinding naar poort 23 en verzond elke byte precies zoals deze werd getypt. Niets was versleuteld, inclusief uw wachtwoord. Iedereen die het netwerkverkeer kon inzien, kon dit lezen: een persoon op hetzelfde kantoornetwerk of een beheerder van een router langs het pad. De rlogin-familie had dezelfde zwakte en vertrouwde de clientmachine op basis van de naam, wat betekent dat men vertrouwde op wat het netwerk beweerde dat die naam was.

Tatu Ylönen schreef de eerste SSH in 1995 aan de Helsinki University of Technology, na een aanval waarbij wachtwoorden werden onderschept op het universiteitsnetwerk. Het ontwerp behoudt het nuttige deel van telnet, een bytestroom tussen uw terminal en een remote shell, en voegt de twee zaken toe waar telnet geen antwoord op heeft: versleuteling van de stroom en het bewijs dat de server aan de andere kant de server is die u wilde bereiken.

Dat tweede deel is gemakkelijk over het hoofd te zien, en het vormt de helft van wat SSH is. Versleuteling alleen zou u niet redden. Een machine in het midden zou uw verbinding kunnen accepteren, deze perfect kunnen versleutelen, alles kunnen lezen wat u verzendt en dit kunnen doorsturen naar de echte server. SSH blokkeert dit door elke server een permanente identiteit te geven, de host key genaamd, en deze bij elke verbinding te controleren.

Hoe het client-servermodel werkt

Er zijn twee programma's. Op de server draait sshd continu en wacht op verbindingen. Op uw machine brengt ssh deze tot stand. Het zijn afzonderlijke programma's met eigen configuratiebestanden; het verwarren van deze twee is de meest voorkomende reden waarom een aanpassing geen effect heeft.

• De server leest /etc/ssh/sshd_config. Hier wordt wachtwoordauthenticatie uitgeschakeld en de luisterpoort ingesteld.
• De client leest /etc/ssh/ssh_config voor systeeminstellingen en vervolgens ~/.ssh/config voor uw eigen instellingen per host.

Op Debian en Ubuntu heet de service-unit ssh. Op RHEL, Rocky en Fedora heet deze sshd. Recente Ubuntu-releases installeren deze met socket-activatie, waardoor systemctl status ssh de status inactive (dead) kan rapporteren terwijl de machine uitstekend bereikbaar is; ssh.socket is namelijk de unit die luistert en de service op verzoek start.

De client hoeft niet per se OpenSSH te zijn. PuTTY op Windows, Termius op een telefoon en de ingebouwde ondersteuning voor externe verbindingen in editors spreken allemaal hetzelfde protocol naar dezelfde sshd. Windows 10 en 11 bevatten ook de OpenSSH-client, waardoor ssh you@server direct in PowerShell werkt zonder dat er iets geïnstalleerd hoeft te worden.

Waarom gebruikt SSH poort 22?

Een poort is een nummer dat de kernel vertelt bij welk luisterend programma een inkomende verbinding hoort, en poorten op Linux werken op dezelfde manier voor elke service. SSH gebruikt 22 omdat IANA dit in 1995 heeft toegewezen. Ylönen vroeg om een vrij nummer naast de protocollen die SSH moest vervangen: 21 was FTP, 23 was telnet en 22 was ongebruikt.

Omdat 22 de standaard is, gaat alles ervan uit. Uw Git-remote, uw back-upscript en het configuratiescherm van uw provider proberen allemaal eerst 22. Dat geldt ook voor elke geautomatiseerde scanner op het internet. Een nieuwe server met wachtwoordauthenticatie ingeschakeld begint binnen enkele minuten na het opstarten regels zoals deze te verzamelen in /var/log/auth.log:

Failed password for invalid user admin from 203.0.113.55 port 43122 ssh2

Dat verkeer is constant en niet persoonlijk op u gericht. Het verplaatsen van sshd naar poort 2222 verwijdert het merendeel van die regels, omdat de scanners het hele internet afzoeken op 22 in plaats van uw server te bestuderen. Het maakt de machine niet moeilijker om binnen te dringen voor iemand die er daadwerkelijk naar kijkt. Beschouw een poortwijziging als ruisonderdrukking en niets meer.

U kunt zien hoe de server antwoordt voordat u überhaupt inlogt:

nc 203.0.113.10 22

Op Ubuntu 24.04 print dat iets dat lijkt op SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13. De banner wordt in leesbare tekst verzonden, voordat er enige versleuteling bestaat, omdat beide partijen deze nodig hebben om het eens te worden over de protocolversie. Druk op Ctrl+C om de verbinding te sluiten.

Wat er op de lijn gebeurt bij een verbinding

De onderstaande reeks is wat een ssh you@server uitvoert voordat u een prompt ziet.

1. De client vertaalt de hostnaam naar een IP-adres en opent vervolgens een TCP-verbinding naar poort 22.
2. Beide partijen sturen hun versiebanner in leesbare tekst (cleartext).
3. Beide partijen sturen de lijsten met algoritmen die zij ondersteunen: sleuteluitwisseling, cijfer, berichtauthenticatie en compressie. Dit gebeurt nog steeds in leesbare tekst. De sterkste optie die beide partijen ondersteunen, wordt gekozen.
4. De sleuteluitwisseling vindt plaats. Huidige OpenSSH geeft de voorkeur aan curve25519-sha256. Beide uiteinden beschikken uiteindelijk over hetzelfde gedeelde geheim zonder dat dit geheim ooit over het netwerk wordt verstuurd. Iemand die het volledige gesprek heeft opgenomen, kan dit achteraf dus niet achterhalen.
5. De server ondertekent het resultaat van die uitwisseling met zijn private hostsleutel. Uw client controleert de handtekening aan de hand van de publieke hostsleutel die in het bestand staat. Dit is de stap die voorkomt dat een machine in het midden zich voordoet als uw server.
6. De versleuteling start. chacha20-poly1305@openssh.com is het standaardcijfer in de huidige OpenSSH.
7. Pas nu authenticeert de client u, met een wachtwoord of een sleutel. Uw gebruikersnaam en wachtwoord reizen binnen het versleutelde kanaal.
8. De client opent een kanaal en vraagt om een shell.

De volgorde in die lijst is het volledige verschil met telnet. Authenticatie vindt plaats nadat het kanaal is versleuteld en nadat de server zijn identiteit heeft bewezen. Er is dus geen moment waarop uw wachtwoord onversleuteld over de lijn gaat.

Iemand die het netwerk in de gaten houdt, leert nog steeds iets. Zij zien uw IP-adres, het IP-adres van de server, poort 22, beide versiebanners in leesbare tekst, en de timing en geschatte grootte van elk pakket. Zij zien niet uw gebruikersnaam, uw wachtwoord, uw commando's of de uitvoer daarvan. De hostnaam-opzoeking in stap 1 maakt geen deel uit van SSH en is meestal niet privé, dus de DNS-query die uw servernaam vertaalt kan onthullen welke machine u gaat bereiken, ook al blijft de sessie zelf afgeschermd.

De host key en de prompt voor de eerste verbindingsvingerafdruk

Wanneer openssh-server wordt geïnstalleerd, genereert het host key-paren voor de machine en schrijft deze naar /etc/ssh/, bijvoorbeeld ssh_host_ed25519_key en ssh_host_ed25519_key.pub. Het private gedeelte verlaat de server nooit. Het public gedeelte is de identiteit van de server en dit is waartegen de handtekening in stap 5 wordt gecontroleerd.

De eerste keer dat u verbinding maakt met een nieuwe server, heeft uw client niets om mee te vergelijken, dus stelt deze u de volgende vraag:

The authenticity of host '203.0.113.10 (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:E9nVQ5Sm2oQ3nGm5Zf1tOaU7Xh0k2p8bWc4dLrTvYxA.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

De vingerafdruk is een SHA256-hash van de public host key, weergegeven in base64, zodat deze kort genoeg is om visueel te vergelijken. Door yes te typen, wordt die key weggeschreven naar ~/.ssh/known_hosts op uw eigen machine. Elke latere verbinding met hetzelfde adres vergelijkt de key die de server aanbiedt met de opgeslagen key. Wanneer deze overeenkomen, wordt er niets afgedrukt en gaat u direct door naar uw prompt.

Dit model wordt "trust on first use" genoemd en het is belangrijk om eerlijk te zijn over wat dit inhoudt. De eerste verbinding is het enige moment waarop u onbeschermd bent, omdat u een key accepteert die u nog nooit eerder hebt gezien. Om dat gat te dichten, kunt u de vingerafdruk via een ander kanaal opvragen en vergelijken. De meeste providers tonen deze in de boot-output van hun webconsole, en u kunt deze ook op de server zelf opvragen:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Dit drukt dezelfde SHA256:-tekenreeks af die de prompt u toonde. De [fingerprint]-keuze in de prompt bestaat precies hiervoor: plak de vingerafdruk die u verwacht, en de client gaat alleen door als deze overeenkomt met wat de server presenteerde.

Op Debian en Ubuntu wordt known_hosts standaard gehasht, waardoor het bestand regels bevat die beginnen met |1| in plaats van leesbare hostnamen. Voer ssh-keygen -F 203.0.113.10 uit om de vermelding voor een specifieke host te vinden.

Waarom meldt SSH dat de host key is gewijzigd?

Vroeg of laat zult u deze muur van tekst tegenkomen:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Deze eindigt met Host key verification failed. en de client weigert de verbinding tot stand te brengen. Ook wordt Password authentication is disabled to avoid man-in-the-middle attacks. getoond, omdat het invoeren van uw wachtwoord op een onbekende machine precies het risico is dat deze controle moet voorkomen.

Het bericht oogt als een noodgeval, maar meestal is dat het niet. De gebruikelijke oorzaken zijn:

• U heeft de server opnieuw opgebouwd of geïnstalleerd, waardoor sshd bij de eerste boot nieuwe host keys heeft gegenereerd. Dit is veruit de meest voorkomende reden.
• U heeft een VPS verwijderd en een nieuwe aangemaakt, waarbij de provider het oude IP-adres aan de nieuwe machine heeft toegewezen.
• U maakt verbinding via een forward of load balancer die nu een andere backend-machine bereikt.
• Er onderschept daadwerkelijk iemand de verbinding.

Bepaal wat de oorzaak is voordat u iets verwijdert. Als u de machine tien minuten geleden opnieuw heeft geïnstalleerd, is de oorzaak duidelijk. Als er aan uw kant niets is veranderd, stop dan en onderzoek de situatie, want deze waarschuwing is de controle die zijn werk doet. Zodra u zeker bent, verwijdert u het verouderde item en maakt u opnieuw verbinding:

ssh-keygen -R 203.0.113.10

De volgende verbinding toont opnieuw de prompt voor de fingerprint, waardoor u een nieuwe kans krijgt om deze te vergelijken met de console van de provider.

Wachtwoordauthenticatie versus sleutelauthenticatie

Wachtwoordauthenticatie verstuurt uw wachtwoord binnen het reeds versleutelde kanaal, en sshd controleert dit tegen de accountdatabase, doorgaans via PAM (pluggable authentication modules). Dit vereist geen voorbereiding, wat de reden is dat een provider u een nieuwe server kan opleveren met enkel een root-wachtwoord.

De zwakte ligt niet in de versleuteling. Het probleem is dat een wachtwoord een kort geheim is, u het bij elke aanmelding naar de server verstuurt, en poort 22 dag en nacht wordt aangevallen door bots die nooit vermoeid raken.

Public key-authenticatie werkt anders. U maakt een sleutelpaar aan op uw eigen machine. De publieke helft plaatst u in ~/.ssh/authorized_keys binnen uw account op de server. De private helft blijft op uw laptop en wordt nooit verzonden. Om in te loggen ondertekent de client een stuk data dat de sessie-identifier van de sleuteluitwisseling bevat, en de server verifieert die handtekening met de publieke sleutel die hij al bezit. Omdat de ondertekende data gekoppeld is aan deze specifieke sessie, is een onderschepte handtekening waardeloos voor andere doeleinden.

Let goed op de richting, want het omdraaien hiervan komt vaak voor en is schadelijk: de publieke sleutel gaat naar de server, de private sleutel blijft bij u. Een private sleutel die naar een server is gekopieerd, is een sleutel die u niet langer kunt vertrouwen.

Sleutelauthenticatie kent eigen storingsmodi. sshd negeert sleutels wanneer de bestandsrechten te ruim zijn, en dit wordt vermeld in het serverlogboek:

Authentication refused: bad ownership or modes for directory /home/ubuntu/.ssh

De client meldt u enkel Permission denied (publickey), wat dezelfde melding is voor een dozijn verschillende oorzaken. Daarom is het de moeite waard om de publickey-foutmelding correct te interpreteren voordat u uzelf buitensluit. Het praktische werk van het aanmaken van sleutels, het beveiligen ervan met een wachtwoordzin en het laden in een agent hoort thuis in SSH-sleutelbeheer, en het uitschakelen van wachtwoordauthenticatie zonder uzelf buiten te sluiten hoort thuis in SSH beveiligen op een VPS.

SFTP, scp en port forwarding maken gebruik van dezelfde verbinding

Dit is het concept dat de rest van de SSH-wereld op zijn plek laat vallen. Authenticatie opent een versleutelde verbinding en die verbinding kan meerdere onafhankelijke kanalen tegelijkertijd dragen. Een shell is slechts één type kanaal van de vele.

• Een remote shell. ssh you@server opent een sessiekanaal en vraagt om een interactieve shell.
• Een enkel commando. ssh you@server uptime opent een kanaal, voert één commando uit, toont de uitvoer en sluit af.
• SFTP. De client vraagt aan sshd om het sftp-subsysteem te starten, en bestandsoverdracht vindt plaats binnen dezelfde verbinding. SFTP is een protocol voor bestandsoverdracht dat via SSH verloopt en deelt geen ontwerpkenmerken met FTP. Het protocol dat FTP is met toegevoegde versleuteling heet FTPS en staat hier los van.
• scp. Kopieert bestanden met gebruik van dezelfde login. Sinds OpenSSH 9.0, uitgebracht in 2022, gebruikt scp standaard het SFTP-protocol op de achtergrond.
• Port forwarding. ssh -L 8080:localhost:80 you@server verandert poort 8080 op uw laptop in een toegangspoort naar poort 80 op de server, die binnen de versleutelde verbinding wordt getransporteerd. -R forwardt in de andere richting en -D 1080 verandert de sessie in een SOCKS-proxy.
• Git. Een remote zoals git@github.com:user/repo.git is een SSH-login waarvan de externe zijde een commandohandler uitvoert in plaats van een shell.
• rsync en Ansible zijn ook SSH-clients. Zij openen een kanaal, voeren iets uit en lezen de uitvoer terug.

Elk item op deze lijst gebruikt dezelfde poort, dezelfde host key-controle en dezelfde inloggegevens. Daarom loont het instellen van key-authenticatie direct: al deze tools erven deze instelling over. Dit is ook de reden waarom hetzelfde ~/.ssh/config-bestand dat uw logins verkort, het bestand is dat schaalt wanneer u meerdere Linux-servers beheert vanaf één laptop.

Wat SSH niet doet

• Het maakt uw server niet veilig. SSH beschermt het pad naar de deur. De deur is er nog steeds en men zal aan de klink blijven voelen. Het blokkeren van herhaalde inlogpogingen met fail2ban vangt het volume op, en authenticatie uitsluitend via sleutels verwijdert hetgeen zij proberen te raden.
• Het beschermt u niet tegen uw eigen machine. Iedereen met toegang tot uw laptop beschikt over uw privésleutel en uw geladen agent.
• Het verbergt niet dat u SSH gebruikt. Het poortnummer en de versiebanner in platte tekst maken dit kenbaar.
• Het dekt niet wat er gebeurt voordat de verbinding tot stand komt. De naamopzoeking en uw beslissing welk adres u vertrouwt, vinden beide eerst plaats.

Vervolgstappen

Als u momenteel een nieuwe server in een provider-console open heeft staan, is de logische volgorde vaststaand. Log in, maak een normale gebruiker aan, installeer uw key en sluit daarna de eenvoudige toegangswegen af. De eerste tien minuten op een nieuwe VPS doorloopt deze volgorde van begin tot eind, en wat een VPS daadwerkelijk is biedt achtergrondinformatie over de machine als de terminologie nog nieuw voor u is. Lees daarna de artikelen over keys en hardening, in die specifieke volgorde.

FAQ

Waar staat SSH voor?

SSH staat voor secure shell. Het is een protocol om in te loggen op een externe computer en daarop commando's uit te voeren via een versleutelde verbinding, gedefinieerd in RFC 4251 tot en met RFC 4254. OpenSSH is de implementatie die vrijwel iedereen gebruikt: de ssh client op uw machine en de sshd server op de externe machine. Het verving telnet, dat alles, inclusief wachtwoorden, in platte tekst over het netwerk verstuurde.

Waarom gebruikt SSH poort 22?

IANA wees in 1995 poort 22 toe aan SSH, naast FTP op 21 en telnet op 23, de protocollen die het moest vervangen. Niets dwingt het gebruik van dat nummer af: Port in /etc/ssh/sshd_config wijzigt dit op de server, en ssh -p kiest een andere poort op de client. Omdat 22 de standaard is, kloppen geautomatiseerde scanners er constant op aan; daarom raakt de /var/log/auth.log van een nieuwe server gevuld met Failed password for invalid user regels. Het wijzigen van de poort vermindert die ruis, maar biedt geen echte beveiliging.

Wat moet ik doen als SSH waarschuwt dat de host key is gewijzigd?

Zoek naar de oorzaak voordat u iets verwijdert. De gebruikelijke reden is onschuldig: de server is opnieuw opgebouwd, waardoor sshd nieuwe host keys heeft gegenereerd, of een nieuwe machine heeft het oude IP-adres gekregen. Als u weet dat de machine opnieuw is opgebouwd, voer dan ssh-keygen -R <host> uit om de opgeslagen key te verwijderen, maak opnieuw verbinding en vergelijk de getoonde vingerafdruk met die in de console van uw provider. Als er aan uw kant niets is veranderd, maak dan geen verbinding en voer uw wachtwoord niet in. OpenSSH weigert in deze staat al wachtwoordauthenticatie om precies die reden.

Zijn SFTP en scp anders dan SSH?

Ze draaien bovenop SSH. Zodra u bent geauthenticeerd, kan de SSH-verbinding meerdere kanalen dragen, en een shell is er daar slechts één van. SFTP is een bestandsoverdrachtprotocol dat het sftp subsysteem van sshd gebruikt over diezelfde verbinding, en scp gebruikt sinds OpenSSH 9.0 het SFTP-protocol als basis. Port forwarding en Git over SSH zijn eveneens kanalen op dezelfde verbinding. Ze gebruiken allemaal dezelfde poort, dezelfde host key-controle en dezelfde login. Let op: SFTP is niet FTP met toegevoegde versleuteling; dat heet FTPS en is een afzonderlijk protocol.

Is key-authenticatie echt beter dan een wachtwoord?

Ja, voor elke server die bereikbaar is vanaf het internet. Een wachtwoord is een kort geheim dat u bij elke login aan de server verstrekt, en poort 22 wordt continu aangevallen door geautomatiseerde clients. Bij een key-paar verlaat het private deel nooit uw machine: de client ondertekent gegevens die gekoppeld zijn aan de huidige sessie, en de server controleert die handtekening tegen de public key in ~/.ssh/authorized_keys. Een opgenomen handtekening kan niet worden hergebruikt tegen een andere server. Beveilig de private key met een passphrase, want een key-bestand zonder passphrase is een werkende login voor iedereen die het kopieert.