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 dit wachtwoord lezen, en begin jaren 90 gebeurde dit op grote schaal.

SSH was het antwoord van één persoon op dat 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 vandaag de dag 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 verstuurd als leesbare tekst die elk apparaat op het pad kan onderscheppen.

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) waarin staat: "Het omzeilen van wachtwoordauthenticatie van vertrouwde hosts stelt ALLE zo geconfigureerde systemen bloot wanneer er slechts één gecompromitteerd is." Er wordt ook opgemerkt dat het 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 werden 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 negeerde – wat de betekenis is van promiscuous mode – kon het verkeer van alle andere apparaten inzien. Als men daarbij bedenkt dat universiteiten shell-accounts verstrekten aan duizenden studenten, werd één gecompromitteerd account al snel 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 inloggegevens hadden buitgemaakt 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, is 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 wachtwoord-sniffing-aanval, van het type dat CERT eerder 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 vormden de basis. De sessie werd versleuteld, waardoor een meeluisteraar op het netwerksegment geen bruikbare informatie kon onderscheppen. Daarnaast bewees de server zijn identiteit met een sleutel, zodat de client kon verifiëren of deze de juiste machine had 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 gewend waren te typen. ssh verving rsh en rlogin, terwijl scp in de plaats kwam van rcp. De overstap vereiste slechts een verandering van gewoonte, geen verandering van werkproces. Tegen het einde van 1995 was het gebruikersbestand gegroeid naar 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 de mogelijkheden van anderen om de code te gebruiken beperkten, 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 doorging waar die wereld niet kon volgen. Licenties bepalen welke code overleeft, een patroon waarover u meer kunt lezen in hoe open source-licenties moderne infrastructuur hebben gevormd.

Waarom OpenBSD in 1999 een fork van OpenSSH maakte

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 herbouwde het. Volgens het verslag 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 meegeleverd 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 geauditeerd basissysteem dat in de standaardconfiguratie veilig moet zijn; daarom moest versleuteld inloggen op afstand in dat basissysteem aanwezig zijn, onder een licentie zonder beperkingen. Geauditeerde 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, 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 gebruiken is de reden waarom die lijm überhaupt nodig is.

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

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

SSH-1 beschermde de integriteit van de versleutelde stroom met CRC-32, een controlesom die ontworpen was om transmissiefouten op te vangen in plaats van weerstand te bieden aan 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 platte tekst kent, gekozen cijfertekst 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 bevatten. 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 aspect, omdat elke laag daarna 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 in handen kreeg, een opgenomen sessie kon ontsleutelen. Diffie-Hellman leidt per sessie een vers geheim af dat nooit wordt verzonden, dus het nu opnemen van verkeer en later stelen van de hostsleutel levert niets op. Deze eigenschap wordt forward secrecy genoemd.

SSH-2 deelt geen wire-compatibiliteit met SSH-1. Daarom is het nummer veranderd 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 ondersteuning aan de serverzijde. Versie 7.6, op 3 oktober 2017, verwijderde ook de clientzijde, 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 meegecompileerd, en deze bevond zich in een pad waarvan de meeste beheerders dachten dat het inactief was op hun systemen. Code die wordt uitgeleverd, kan worden bereikt. Code die is verwijderd, kan dat niet.

Waarom uw eerste SSH-verbinding waarschuwt over de host key

Versleuteling garandeert dat het verkeer privé is. Het vertelt u echter niet wie er aan de andere kant zit. Als een aanvaller zich in het pad bevindt en in plaats van uw server antwoordt, 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 hij de private helft van een sleutelpaar bezit, en de client controleert die sleutel tegen wat er de vorige keer is opgeslagen. Voor de technische werking van de verbinding zelf, zie wat er gebeurt bij het openen van een SSH-verbinding.

Bij de eerste verbinding is er geen vorige keer, dus de client heeft niets om te vergelijken en moet het aan u 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 waarde met de opgeslagen waarde, en een mismatch resulteert in de meest alarmerende melding die het programma heeft:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 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 dat gat dichten. Lees de vingerafdruk (fingerprint) uit 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 en niet elke individuele sleutel. In de praktijk accepteren de meeste mensen de prompt zonder controle, en het is de moeite waard om daar eerlijk over te zijn.

Hoe publieke sleutels wachtwoorden hebben vervangen

Authenticatie met 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 doet het tegenovergestelde. Hoewel SSH dit binnen het versleutelde kanaal verstuurt, ontvangt de server het daadwerkelijke geheim. Hierdoor kan een gecompromitteerde of kwaadwillende server het wachtwoord in handen krijgen en elders tegen u gebruiken.

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 te raden tekenreeks. Een sleutel is in de praktijk niet te raden. Met PasswordAuthentication no schakelt u deze hele aanvalscategorie uit. Daarom staat deze instelling op elke hardening-checklist. U verwijdert daarmee ook de fallback die u vroeger kon redden wanneer er iets misging met een sleutel. Leer daarom de verschillende fouten onderscheiden die allemaal Permission denied (publickey) melden voordat u zelf wordt buitengesloten. Werken zonder wachtwoorden betekent ook dat u steeds meer sleutels verzamelt. Een agent die er een dozijn bevat, biedt ze allemaal achter elkaar aan totdat de server de limiet voor pogingen bereikt en de verbinding verbreekt. Dat is de reden waarom een login kan mislukken met Too many authentication failures, zelfs wanneer de juiste sleutel is geladen. Het genereren en rouleren van sleutels wordt behandeld in de basisprincipes van SSH-sleutelbeheer. De serverinstellingen vindt u in SSH hardenen 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 formaat voor privésleutels 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 privésleutel niet kan lekken. Dit is precies hoe DSA- en ECDSA-privésleutels 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 160-bit privésleutel 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 volledig, 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 vindt nu plaats voor sleuteluitwisseling, ditmaal vooruitlopend op de dreiging. Verkeer dat vandaag wordt onderschept, kan worden opgeslagen en jaren later worden 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 tegenvallen. OpenSSH 9.9, op 19 september 2024, voegde mlkem768x25519-sha256 toe, gebaseerd op ML-KEM (module lattice key encapsulation mechanism), dat in 2024 door NIST werd gestandaardiseerd. 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 het geven van waarschuwingen 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.

Deze 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 algoritmen voor handtekeningen en de codebasis zelf. Dat was alleen mogelijk omdat elke vervanging eindigde in een bewuste verwijdering, en elke verwijdering betekende voor iemand een breuk in de functionaliteit.

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. Per 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 niemand in drie jaar 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 ontwikkeld 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 als leesbare tekst over het netwerk. Iedereen die een gedeeld netwerksegment monitorde, kon zodoende 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 niet compatibel zijn met elkaar. SSH-1 was een enkel monolithisch protocol dat CRC-32 gebruikte voor integriteit en waarbij de client een sessiesleutel versleutelde 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 netwerkverkeer 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 bij de eerste verbinding?

Omdat de client die server nog nooit eerder heeft gezien en geen sleutel heeft om mee te vergelijken. Versleuteling alleen kan een eerlijke server niet onderscheiden van een machine die zich in het midden van het pad bevindt, dus 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 exemplaar dat u hebt verkregen via de console van de provider of de server zelf, en beschouw elk later bericht over 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 volgens een gepubliceerd schema algoritmen uitfaseert. DSA (ssh-dss) sleutels werden in 2015 standaard uitgeschakeld in OpenSSH 7.0 en op 9 april 2025 volledig verwijderd in OpenSSH 10.0. RSA-sleutels werken nog steeds, maar handtekeningen gemaakt met SHA-1 werden in september 2021 standaard uitgeschakeld in OpenSSH 8.8, wat zich uit als sign_and_send_pubkey: no mutual signature supported wanneer u een oude server benadert. Een Ed25519-sleutel, beschikbaar sinds OpenSSH 6.5 in januari 2014, voorkomt beide problemen.