Geschiedenis van SSH: van telnet naar OpenSSH

Waar de geschiedenis van SSH begint

De geschiedenis van SSH begint bij gestolen wachtwoorden. Vóór 1995 betekende inloggen op een externe Unix-machine het gebruik van telnet of rlogin, waarbij beide protocollen uw wachtwoord als leesbare tekst over het netwerk verstuurden. Iedereen die het netwerkverkeer kon monitoren, kon het wachtwoord lezen, en begin jaren 90 gebeurde dit op grote schaal.

SSH was het antwoord van één persoon op dit probleem; het werd in 1995 geschreven en gratis beschikbaar gesteld. Het protocol is sindsdien één keer volledig opnieuw opgebouwd en het programma dat bijna iedereen tegenwoordig gebruikt, is een fork van een fork. De onderstaande data zijn van belang, omdat elke stap een reactie was op een specifiek falen.

Wat telnet en rlogin daadwerkelijk verstuurden

Telnet is gedefinieerd in RFC 854, gepubliceerd in mei 1983 door Jon Postel en Joyce Reynolds. Het beschrijft een terminalsessie die over TCP wordt uitgevoerd en bevat geen enkele vorm van versleuteling. Elke byte die u typt, inclusief uw wachtwoord, wordt als leesbare tekst verzonden die elk apparaat op het netwerkpad kan uitlezen.

rlogin kwam voort uit Berkeley Unix en werd later beschreven in RFC 1282 (BSD Rlogin, B. Kantor, december 1991). Het voegde iets toe dat nog erger was dan een leesbaar wachtwoord: op host gebaseerd vertrouwen. Een server kon worden geconfigureerd om inlogpogingen van een specifieke host zonder wachtwoord te accepteren. De RFC bevat een sectie genaamd "A Cautionary Tale" (Een waarschuwend verhaal) die stelt: "Het omzeilen van wachtwoordauthenticatie vanaf vertrouwde hosts stelt ALLE aldus geconfigureerde systemen bloot wanneer er slechts één gecompromitteerd raakt." Er wordt ook opgemerkt dat dit vertrouwen gebaseerd is op hostnamen, waardoor een DNS-compromis (domain name system) of een gespoofed adres de beveiliging volledig tenietdoet.

Beide ontwerpen waren geschikt voor het netwerk waarvoor ze destijds zijn ontwikkeld. Vroege Ethernet-netwerken waren een gedeeld medium: elke machine op een segment ontving elk frame en werd geacht frames die niet aan het eigen adres waren gericht te negeren. Een machine die deze frames niet langer negeerde – wat de betekenis is van promiscuous mode – kon het verkeer van alle andere apparaten inzien. Als men daarbij bedenkt dat een universiteit shell-accounts verstrekte aan duizenden studenten, kon één gecompromitteerd account fungeren als een wachtwoordverzamelaar voor een gehele afdeling.

Het advies uit 1994 waarvoor geen oplossing bestond

Op 3 februari 1994 publiceerde CERT het advies CA-94:01, "Ongoing Network Monitoring Attacks". Hierin werd gemeld dat aanvallers toegangsgegevens hadden onderschept van tienduizenden systemen op het internet. De gebruikte tool zette de netwerkinterface in promiscuous mode en legde het begin van elke nieuwe telnet-, rlogin- en FTP-sessie vast; dit is het gedeelte dat de gebruikersnaam en het wachtwoord bevat.

CERT adviseerde beheerders om het wachtwoord van elk account dat via het netwerk toegankelijk was te wijzigen. Als men dit afzet tegen de protocollen, wordt de valstrik duidelijk: het nieuwe wachtwoord wordt bij het eerste gebruik in leesbare tekst over dezelfde verbinding verstuurd. Er bestond geen oplossing binnen telnet of rlogin, omdat geen van beide protocollen de mogelijkheid bood om een dergelijke beveiliging te implementeren.

Waarom een sniffing-aanval in Helsinki leidde tot SSH

In 1995 werd het netwerk van de Technische Universiteit Helsinki getroffen door een password sniffing-aanval van het type dat CERT had beschreven. Tatu Ylönen, een onderzoeker aldaar, schreef een vervanger en bracht deze in juli 1995 uit als freeware. Hij noemde het Secure Shell.

Twee ontwerpbeslissingen zorgden voor het succes. De sessie werd versleuteld, waardoor een meeluisteraar op het netwerksegment geen bruikbare informatie kon onderscheppen. Daarnaast bewees de server zijn identiteit met een key, zodat de client kon vaststellen of de juiste machine was bereikt; dit was het beveiligingslek dat bij rlogin door het vertrouwen op hostnamen openbleef.

Het verspreidde zich ook omdat de commando's overeenkwamen met wat mensen al gebruikten. ssh verving rsh en rlogin, scp verving rcp. De overstap kostte slechts een gewoonte, geen verandering van workflow. Eind 1995 telde de gebruikersgroep ongeveer 20.000 gebruikers in vijftig landen. In december van dat jaar richtte Ylönen SSH Communications Security op om de software verder te ontwikkelen en te verkopen.

Van een vrije release naar een commercieel product

Toen SSH een commerciële onderneming werd, veranderde de licentie op de broncode. Latere releases bevatten voorwaarden die beperkten wat anderen met de code mochten doen, en de laatste release die iedereen vrij kon hergebruiken was ssh 1.2.12. Daar is niets mis mee. Het betekende simpelweg dat de versie van SSH waarop de rest van de wereld kon voortbouwen niet meer verder werd ontwikkeld, terwijl de ontwikkeling elders werd voortgezet waar die wereld niet kon volgen. Licenties bepalen welke code overleeft; een patroon waarover het de moeite waard is om te lezen in hoe open source-licenties moderne infrastructuur hebben gevormd.

Waarom OpenBSD in 1999 een fork maakte van OpenSSH

Begin 1999 keerde Björn Grönvall terug naar die laatste vrije release en begon hij bugs daarin te verhelpen. Zijn versie heette OSSH en ondersteunde alleen het SSH 1.3-protocol.

Het OpenBSD-project nam OSSH over en bouwde het opnieuw op. Volgens het relaas van het project zelf verrichtten Theo de Raadt, Niels Provos, Markus Friedl, Bob Beck, Aaron Campbell en Dug Song het werk om de code op te schonen, te auditen en uit te breiden. Het resultaat was OpenSSH 1.2.2, dat op 1 december 1999 werd uitgebracht met OpenBSD 2.6.

Waarom belandde een fork van een klein besturingssysteemproject op bijna elke machine? Vanwege wat OpenBSD ervan nodig had. OpenBSD levert een geaudit basissysteem dat in de standaardconfiguratie veilig moet zijn, dus moest versleuteld inloggen op afstand in dat basissysteem aanwezig zijn, onder een licentie zonder beperkingen. Geaudite code onder een onbeperkte licentie is precies wat elke andere leverancier van besturingssystemen ook wilde. Damien Miller, Philip Hands en anderen startten vrijwel direct een portable branch; dit is waar de p in een versie zoals 10.5p1 vandaan komt. OpenBSD ontwikkelt de schone versie en de portable branch voegt de lijm toe voor alle andere systemen. De manier waarop Unix uiteenviel in de systemen die we vandaag draaien is de reden waarom die lijm überhaupt nodig is.

Ondersteuning voor de tweede protocolversie volgde. OpenSSH 2.0 werd op 15 juni 2000 uitgebracht met OpenBSD 2.7.

Waarom SSH-2 een nieuw protocol is en geen versie-update

SSH-1 beschermde de integriteit van de versleutelde stream met CRC-32, een checksum die ontworpen was om transmissiefouten op te vangen in plaats van weerstand te bieden tegen een aanvaller. In 1998 toonden Ariel Futoransky en Emiliano Kargieman van CORE SDI aan wat de gevolgen hiervan zijn. Bij CBC- of CFB-cijfermodi en een CRC-32-controle kan een aanvaller die slechts 16 bytes van de plaintext kent, gekozen ciphertext invoegen die de ontvanger als authentiek accepteert, wat betekent dat er commando's op de server kunnen worden uitgevoerd.

Het defect zat in het protocol zelf, waardoor het niet kon worden gecorrigeerd zonder de compatibiliteit te verbreken. Implementaties leverden in plaats daarvan een detector mee, code in een bestand genaamd deattack.c die probeerde de aanval te herkennen zodra deze plaatsvond. In februari 2001 bleek de detector zelf een integer overflow te bevatten, CVE-2001-0144, wat leidde tot remote code execution op servers en clients die de patch hadden toegepast. Een ontwerp dat niet kan worden gerepareerd, verzamelt patches, en de patches brengen hun eigen bugs met zich mee.

SSH-2 werd uitgewerkt in een IETF-werkgroep genaamd secsh en in januari 2006 gepubliceerd als RFC's: de architectuur in RFC 4251, de transportlaag in RFC 4253, gebruikersauthenticatie in RFC 4252 en de verbindingslaag in RFC 4254. De opsplitsing in lagen is het belangrijkste onderdeel, omdat elke laag vervolgens afzonderlijk kan worden vervangen. Het grootste deel van de rest van deze geschiedenis bestaat uit het plaatsvinden van die vervanging.

Twee wijzigingen springen eruit. De integriteitscontrole verschoof van CRC-32 naar een HMAC (hash-based message authentication code) die wordt gesleuteld met een gedeeld geheim, waardoor een aanvaller die de MAC niet kan berekenen, geen pakket kan vervalsen. Daarnaast verschoof de sleutelovereenkomst naar Diffie-Hellman. In SSH-1 koos de client de sessiesleutel en stuurde deze versleuteld onder de RSA-sleutels van de server, waardoor iedereen die later die privésleutels verkreeg, een opgenomen sessie kon ontsleutelen. Diffie-Hellman leidt per sessie een vers geheim af dat nooit wordt verzonden, dus het opnemen van verkeer nu en het later stelen van de hostsleutel levert niets op. Deze eigenschap wordt forward secrecy genoemd.

SSH-2 deelt geen wire-compatibiliteit met SSH-1. Dat is de reden waarom het nummer veranderde in plaats van het decimaal.

Waarom SSH-1 werd verwijderd in plaats van gerepareerd

De verwijdering vond plaats over drie OpenSSH releases. Versie 7.0, op 11 augustus 2015, schakelde protocol 1 standaard uit tijdens het compileren. Versie 7.4, op 19 december 2016, verwijderde de serverondersteuning voor dit protocol. Versie 7.6, op 3 oktober 2017, verwijderde ook de client-zijde, inclusief de bijbehorende configuratieopties en documentatie.

Het als optie behouden voor oude apparatuur was de vriendelijkere keuze geweest, maar de CRC-32 detector verklaart waarom die keuze werd afgewezen. De overflow was alleen bereikbaar omdat de code voor protocol 1 was gecompileerd en zich bevond in een pad waarvan de meeste beheerders dachten dat het inactief was op hun systemen. Code die wordt uitgebracht, kan worden bereikt. Code die is verwijderd, kan dat niet.

Waarom uw eerste SSH-verbinding waarschuwt voor de host key

Encryptie garandeert dat het verkeer privé is. Het vertelt u echter niet wie zich aan de andere kant bevindt. Als een aanvaller zich in het netwerkpad bevindt en antwoordt in plaats van uw server, krijgt u een perfect versleutelde sessie met de aanvaller; dit is een machine-in-the-middle-aanval. SSH lost dit op met een host key: de server bewijst dat deze over de private helft van een sleutelpaar beschikt, en de client controleert die sleutel tegen wat er bij een vorige verbinding is opgeslagen. Voor de technische details van de verbinding zelf, zie wat er gebeurt bij het openen van een SSH-verbinding.

Bij de eerste verbinding is er geen eerdere keer, dus de client heeft niets om te vergelijken en moet u het volgende vragen:

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

Door met yes te antwoorden, wordt die sleutel opgeslagen in ~/.ssh/known_hosts. Elke latere verbinding vergelijkt de sleutel met de opgeslagen waarde, en een mismatch resulteert in de meest alarmerende melding die het programma kan geven:

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

De eerlijke interpretatie van die eerste prompt is dat het protocol hier zijn enige zwakke moment toegeeft. Trust on first use betekent dat de eerste verbinding slechts zo veilig is als het netwerk waarover u deze tot stand brengt. U kunt dit gat dichten. Lees de fingerprint af via de console van uw provider of het build-logboek van de server voordat u verbinding maakt. Publiceer deze in DNS als een SSHFP-record (RFC 4255), wat alleen zinvol is als u DNSSEC gebruikt. Of onderteken host keys met uw eigen certificate authority (CA), zodat clients de CA vertrouwen in plaats van elke individuele sleutel. In de praktijk accepteren de meeste mensen de prompt zonder controle, en het is goed om daar eerlijk over te zijn.

Hoe publieke sleutels wachtwoorden hebben vervangen

Authenticatie via publieke sleutels was al aanwezig vanaf de vroege SSH-releases, maar het duurde jaren voordat dit de standaard werd. Het mechanisme is asymmetrisch: de client bewijst dat deze over een privésleutel beschikt door een challenge te ondertekenen, waarbij de privésleutel de client nooit verlaat. Een wachtwoord werkt precies andersom. Hoewel SSH dit binnen het versleutelde kanaal verstuurt, ontvangt de server het daadwerkelijke geheim. Hierdoor kan een gecompromitteerde of kwaadwillende server in het bezit komen van gegevens die elders tegen u kunnen worden gebruikt.

De tweede reden is rekenkundig. Elke server met poort 22 open op een publiek adres ontvangt dag en nacht geautomatiseerde inlogpogingen, en een wachtwoord is een raadbare reeks tekens. Een sleutel is in de praktijk niet te raden. Het instellen van PasswordAuthentication no beëindigt deze gehele categorie van aanvallen, wat de reden is dat dit op elke checklist voor hardening staat. Het genereren en roteren van sleutels wordt behandeld in basisprincipes van SSH-sleutelbeheer, en de instellingen aan de serverzijde in SSH beveiligen op een VPS.

Waarom de lijst met SSH-algoritmen voortdurend verandert

Een gelaagd protocol staat toe dat algoritmen worden uitgefaseerd zonder dat een nieuw protocol nodig is. OpenSSH benut deze vrijheid consequent, en de releasedata tonen het tempo aan.

Ed25519 werd geïntroduceerd in OpenSSH 6.5 op 30 januari 2014, samen met de chacha20-poly1305-cipher en een privesleutelformaat dat wordt beveiligd door bcrypt. Ed25519-handtekeningen leiden hun per-handtekening nonce deterministisch af, waardoor een zwakke generator voor willekeurige getallen tijdens het ondertekenen de privesleutel niet kan lekken. Dat is precies hoe privesleutels van DSA en ECDSA in werkelijke incidenten zijn achterhaald.

DSA bewandelde de omgekeerde weg. OpenSSH 7.0 schakelde ssh-dss host- en gebruikerssleutels uit tijdens runtime in 2015, omdat het algoritme beperkt is tot een privesleutel van 160-bit en SHA-1. Versie 9.8, op 1 juli 2024, schakelde DSA uit tijdens het compileren. Versie 10.0, op 9 april 2025, verwijderde het, in de woorden van het project: "waarmee het uitfaseringsproces dat in 2015 begon, is voltooid". Tien jaar van uitschakelen tot verwijderen.

RSA verdween niet, maar het oude handtekeningformaat wel. OpenSSH 8.8, op 26 september 2021, stopte standaard met het accepteren van RSA-handtekeningen die met SHA-1 zijn gemaakt. De release notes vermelden de reden duidelijk: SHA-1 is cryptografisch gebroken en 'chosen-prefix'-botsingen waren haalbaar voor minder dan 50.000 USD. Als u ooit sign_and_send_pubkey: no mutual signature supported bent tegengekomen tijdens het verbinden met een oude server, dan is dat deze wijziging. Uw sleutel is in orde. Het handtekeningalgoritme waar de andere kant om vroeg, is dat niet.

Hetzelfde proces loopt nu voor sleuteluitwisseling, ditmaal vooruitlopend op de dreiging. Verkeer dat vandaag wordt onderschept, kan jaren later worden opgeslagen en ontsleuteld door degene die als eerste over een capabele kwantumcomputer beschikt; daarom moest de sleutelovereenkomst veranderen voordat een dergelijke machine bestaat. OpenSSH 9.0, op 8 april 2022, maakte een hybride sleuteluitwisseling de standaard: sntrup761x25519-sha512@openssh.com koppelt een post-kwantumalgoritme aan de X25519-uitwisseling, zodat het resultaat niet zwakker is dan het klassieke deel mocht het nieuwe algoritme tekortschieten. OpenSSH 9.9, op 19 september 2024, voegde mlkem768x25519-sha256 toe, gebaseerd op ML-KEM (module lattice key encapsulation mechanism), in 2024 gestandaardiseerd door NIST. OpenSSH 10.0 maakte dit de standaard voor sleutelovereenkomst, en de post-kwantumpagina van het project legt de redenering uit. OpenSSH 10.1, op 6 oktober 2025, begon met waarschuwen wanneer de andere kant dit niet ondersteunt:

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded.

Die waarschuwing staat standaard aan en wordt beheerd door de optie WarnWeakCrypto in ssh_config. Wat dit in de praktijk betekent, en wat u moet doen bij een server die deze waarschuwing activeert, wordt behandeld in de standaardinstellingen voor post-kwantum SSH-sleuteluitwisseling.

Wat deze geschiedenis betekent voor de server voor u

Het commando dat u typt is sinds 1995 nauwelijks veranderd. Bijna alles daaronder is vervangen: de integriteitscontrole, de sleuteluitwisseling, de signature-algoritmen en de codebasis zelf. Dat was alleen mogelijk omdat elke vervanging eindigde in een bewuste verwijdering, en elke verwijdering brak iets voor iemand.

Uw SSH-beveiliging wordt daarom grotendeels bepaald door uw versie. De standaardinstellingen bevatten de beslissingen over welke algoritmen worden aangeboden, welke worden geweigerd en welke waarschuwingen u ziet. Een oude server blijft aanbieden wat de release destijds toestond, en zal blijven onderhandelen tot het niveau van een oude client. Sinds augustus 2026 is de huidige release OpenSSH 10.5, gepubliceerd op 11 augustus 2026. Het verschil tussen die versie en de versie op een machine waar drie jaar lang niemand naar heeft omgekeken, is de omvang van het probleem. Het controleren hiervan hoort bij de eerste tien minuten op een nieuwe VPS.

FAQ

Wie heeft SSH gemaakt en waarom?

Tatu Ylönen, een onderzoeker aan de Helsinki University of Technology, schreef SSH in 1995 na een aanval waarbij wachtwoorden werden onderschept op het universiteitsnetwerk. De tools voor inloggen op afstand van die tijd, telnet en rlogin, verstuurden wachtwoorden over het netwerk als leesbare tekst. Iedereen die een gedeeld netwerksegment monitorde, kon dus inloggegevens verzamelen terwijl deze voorbijkwamen. Hij bracht het programma in juli 1995 uit als freeware. Tegen het einde van dat jaar had het ongeveer 20.000 gebruikers in vijftig landen, en in december 1995 richtte hij SSH Communications Security op.

Wat is het verschil tussen SSH-1 en SSH-2?

Dit zijn verschillende protocollen die onderling niet compatibel zijn. SSH-1 was een enkel monolithisch protocol dat CRC-32 gebruikte voor integriteit en waarbij de client een sessiesleutel verstuurde die was versleuteld met de RSA-sleutels van de server. SSH-2 splitst het werk op in een transportlaag, een authenticatielaag en een verbindingslaag (RFC 4251 tot 4254, januari 2006), gebruikt een HMAC voor integriteit en leidt sessiesleutels af met Diffie-Hellman. Hierdoor blijft opgenomen verkeer privé, zelfs als de hostsleutel achteraf wordt gestolen. SSH-1 werd in fasen uit OpenSSH verwijderd, wat eindigde met versie 7.6 in oktober 2017.

Waarom verving OpenSSH de oorspronkelijke SSH-implementatie?

De ontwikkeling van het origineel verschoof naar een commercieel product met een restrictieve licentie, en de laatste vrij herbruikbare release was ssh 1.2.12. Begin 1999 blies Björn Grönvall die release nieuw leven in als OSSH, en het OpenBSD-team splitste OSSH af naar OpenSSH, dat op 1 december 1999 werd uitgebracht met OpenBSD 2.6. OpenBSD had gecontroleerde code onder een onbeperkte licentie nodig voor het basissysteem, en die twee eigenschappen zorgen ervoor dat elk ander besturingssysteem dezelfde implementatie kan meeleveren via de portable branch.

Waarom vraagt SSH naar de hostsleutel de eerste keer dat ik verbinding maak?

Omdat de client die server nog nooit eerder heeft gezien en de sleutel nergens mee kan vergelijken. Versleuteling alleen kan een eerlijke server niet onderscheiden van een machine die zich in het midden van het pad bevindt. Daarom identificeert SSH servers op basis van een sleutel en legt het vast wat het heeft gezien in ~/.ssh/known_hosts. De eerste verbinding is het enige moment zonder opgeslagen waarde om te controleren, en daarom vraagt de client het aan u. Vergelijk de vingerafdruk met een vingerafdruk die u hebt verkregen via de console van de provider of de server zelf, en behandel elk later bericht van REMOTE HOST IDENTIFICATION HAS CHANGED als een reële gebeurtenis totdat u deze kunt verklaren.

Waarom werken oudere SSH-sleutels niet meer na een upgrade?

Omdat OpenSSH algoritmen volgens een gepubliceerd schema uitfaseert. DSA (ssh-dss)-sleutels werden standaard uitgeschakeld in OpenSSH 7.0 in 2015 en volledig verwijderd in OpenSSH 10.0 op 9 april 2025. RSA-sleutels werken nog steeds, maar handtekeningen gemaakt met SHA-1 werden standaard uitgeschakeld in OpenSSH 8.8 in september 2021, wat verschijnt als sign_and_send_pubkey: no mutual signature supported wanneer u een oude server bereikt. Een Ed25519-sleutel, beschikbaar sinds OpenSSH 6.5 in januari 2014, voorkomt beide problemen.