SSH-Geschichte: Von Telnet zu OpenSSH

Der Ursprung der SSH-Geschichte

Die Geschichte von SSH beginnt mit gestohlenen Passwörtern. Vor 1995 bedeutete die Anmeldung an einem entfernten Unix-Rechner, telnet oder rlogin zu verwenden. Beide Protokolle übertrugen das Passwort als lesbaren Text über das Netzwerk. Jeder, der den Netzwerkverkehr überwachen konnte, konnte es mitlesen. Anfang der 1990er-Jahre geschah genau das in großem Umfang.

SSH war die Antwort einer einzelnen Person auf dieses Problem. Es wurde 1995 geschrieben und kostenlos bereitgestellt. Das Protokoll wurde seitdem einmal vollständig neu entwickelt. Das Programm, das heute fast alle verwenden, ist ein Fork eines Forks. Die folgenden Jahreszahlen sind relevant, weil jeder Schritt auf einen konkreten Fehler reagierte.

Was Telnet und rlogin tatsächlich übertragen

Telnet ist in RFC 854 definiert, das Jon Postel und Joyce Reynolds im Mai 1983 veröffentlichten. Es beschreibt eine über TCP übertragene Terminalsitzung und verwendet keinerlei Verschlüsselung. Jedes Byte, das Sie eingeben, einschließlich Ihres Passworts, wird als Klartext-Byte übertragen und kann von jedem Gerät auf dem Übertragungsweg gelesen werden.

rlogin entstand aus Berkeley Unix und wurde später in RFC 1282 (BSD Rlogin, B. Kantor, Dezember 1991) beschrieben. Es führte etwas ein, das noch problematischer war als ein lesbares Passwort: vertrauensbasierte Authentifizierung anhand des Hosts. Ein Server konnte so konfiguriert werden, dass er Anmeldungen von einem bestimmten Host ganz ohne Passwort akzeptierte. Das RFC enthält einen Abschnitt mit dem Titel „A Cautionary Tale“ und warnt: „Bypassing password authentication from trusted hosts opens ALL the systems so configured when just one is compromised.“ Außerdem wird darauf hingewiesen, dass das Vertrauen anhand von Hostnamen bestimmt wird. Dadurch können ein kompromittiertes DNS (domain name system) oder eine gefälschte Adresse diese Prüfung umgehen.

Beide Entwürfe passten zu den Netzwerken, für die sie entwickelt wurden. Frühes Ethernet war ein gemeinsam genutztes Medium: Jedes Gerät in einem Segment empfing jeden Frame und sollte die nicht an es adressierten Frames ignorieren. Ein Gerät, das diese Frames nicht mehr ignorierte, befand sich im Promiscuous Mode und konnte den Netzwerkverkehr aller anderen Geräte sehen. Wenn zusätzlich eine Universität Tausenden Studierenden Shell-Konten bereitstellte, konnte ein einziges kompromittiertes Konto als Passwortsammler für ein ganzes Department dienen.

Die Empfehlung von 1994, für die es keinen Fix gab

Am 3 February 1994 veröffentlichte CERT die Empfehlung CA-94:01, „Ongoing Network Monitoring Attacks“. Darin wurde berichtet, dass Angreifer Zugangsdaten für Zehntausende Systeme im Internet aufgezeichnet hatten. Das verwendete Tool versetzte die Netzwerkschnittstelle in den Promiscuous Mode und zeichnete den Anfang jeder neuen telnet-, rlogin- und FTP-Sitzung auf. Dort werden Benutzername und Passwort übertragen.

CERT empfahl den Betreibern, das Passwort für jedes über das Netzwerk erreichbare Konto zu ändern. Betrachtet man diese Empfehlung im Zusammenhang mit den Protokollen, wird das Problem deutlich: Das neue Passwort wird bei seiner ersten Verwendung über dieselbe Leitung im Klartext übertragen. Innerhalb von telnet oder rlogin gab es keine Möglichkeit, diesen Fehler zu beheben, weil keines der beiden Protokolle dafür einen vorgesehenen Mechanismus hatte.

Warum ein Sniffing-Angriff in Helsinki SSH hervorbrachte

1995 wurde das Netzwerk an der Technischen Universität Helsinki von einem Angriff zum Abfangen von Passwörtern getroffen, wie ihn CERT beschrieben hatte. Tatu Ylönen, ein dort tätiger Forscher, entwickelte einen Ersatz und veröffentlichte ihn im Juli 1995 als Freeware. Er nannte ihn Secure Shell.

Zwei Designentscheidungen waren dafür entscheidend. Die Sitzung wurde verschlüsselt, sodass ein Angreifer, der den Netzwerkabschnitt überwachte, keine verwertbaren Informationen erhielt. Außerdem wies der Server seine Identität mit einem Schlüssel nach. Dadurch konnte der Client feststellen, ob er den richtigen Rechner erreicht hatte. Genau diese Lücke ließ das Vertrauen von rlogin in Hostnamen offen.

SSH verbreitete sich auch, weil die Befehle den bereits verwendeten Befehlen entsprachen. ssh ersetzte rsh und rlogin, scp ersetzte rcp. Der Wechsel erforderte eine neue Gewohnheit, aber keinen neuen Arbeitsablauf. Bis Ende 1995 war die Zahl der Benutzer auf ungefähr 20,000 in fünfzig Ländern angewachsen. Im Dezember gründete Ylönen SSH Communications Security, um die Software weiterzuentwickeln und zu verkaufen.

Von einer freien Veröffentlichung zum kommerziellen Produkt

Als SSH zu einem Geschäft wurde, änderte sich die Lizenz für den Quellcode. Spätere Veröffentlichungen enthielten Bedingungen, die einschränkten, was andere mit dem Code tun durften. Die letzte Veröffentlichung, die jeder frei weiterverwenden konnte, war ssh 1.2.12. Daran ist nichts unzulässig. Das bedeutete lediglich, dass die SSH-Version, auf der der Rest der Welt aufbauen konnte, nicht mehr weiterentwickelt wurde. Die Entwicklung lief jedoch an einem Ort weiter, dem diese Welt nicht folgen konnte. Lizenzen bestimmen, welcher Code fortbesteht. Dieses Muster wird in wie Open-Source-Lizenzen die moderne Infrastruktur geprägt haben näher erläutert.

Warum OpenBSD 1999 OpenSSH forkte

Anfang 1999 nahm Björn Grönvall das letzte freie Release wieder auf und begann, darin Fehler zu beheben. Seine Version hieß OSSH und unterstützte nur das SSH-1.3-Protokoll.

Das OpenBSD-Projekt übernahm OSSH und entwickelte es grundlegend weiter. Nach Angaben des Projekts selbst übernahmen Theo de Raadt, Niels Provos, Markus Friedl, Bob Beck, Aaron Campbell und Dug Song die Bereinigung, Prüfung und Erweiterung des Codes. Das Ergebnis war OpenSSH 1.2.2. Es wurde am 1. Dezember 1999 mit OpenBSD 2.6 veröffentlicht.

Warum setzte sich der Fork eines kleinen Betriebssystemprojekts auf fast jeder Maschine durch? Ausschlaggebend waren die Anforderungen von OpenBSD. OpenBSD veröffentlicht ein geprüftes Basissystem, das in der Standardkonfiguration sicher sein soll. Deshalb musste die verschlüsselte Anmeldung per Remote-Zugriff Teil dieses Basissystems sein und unter einer Lizenz stehen, die keine Einschränkungen enthält. Geprüfter Code unter einer uneingeschränkten Lizenz war genau das, was auch alle anderen Betriebssystemanbieter benötigten. Damien Miller, Philip Hands und andere begannen fast sofort mit einem portablen Zweig. Daher stammt das p in einer Version wie 10.5p1. OpenBSD entwickelt die bereinigte Version, während der portable Zweig die Anpassungen für alle anderen Systeme ergänzt. Die Entwicklung von Unix zu den heutigen Systemen erklärt, warum diese Anpassungen überhaupt erforderlich sind.

Die Unterstützung für die zweite Protokollversion folgte in OpenSSH 2.0. OpenBSD 2.7, veröffentlicht am 15. Juni 2000, wurde mit OpenSSH 2.1 ausgeliefert.

Warum SSH-2 ein neues Protokoll und keine Versionsanhebung ist

SSH-1 schützte die Integrität des verschlüsselten Datenstroms mit CRC-32, einer Prüfsumme, die Übertragungsfehler erkennen sollte, nicht aber einem Angreifer widerstehen konnte. 1998 zeigten Ariel Futoransky und Emiliano Kargieman von CORE SDI, welche Folgen das hatte. Bei den Verschlüsselungsmodi CBC oder CFB und einer CRC-32-Prüfung konnte ein Angreifer, der nur 16 Byte des Klartexts kannte, manipulierten Ciphertext einschleusen, den der Empfänger als echt akzeptierte. Dadurch konnten Befehle auf dem Server ausgeführt werden.

Der Fehler lag im Protokoll und konnte daher nicht behoben werden, ohne die Kompatibilität zu brechen. Stattdessen wurde ein Erkennungsmechanismus ausgeliefert. Dabei handelte es sich um Code in einer Datei namens deattack.c, der den Angriff während seiner Ausführung erkennen sollte. Im Februar 2001 wurde festgestellt, dass dieser Erkennungsmechanismus selbst einen Integerüberlauf enthielt, CVE-2001-0144. Dadurch war Remote Code Execution gegen Server und Clients möglich, auf denen der Patch installiert war. Ein Design, das sich nicht reparieren lässt, sammelt Patches an. Diese Patches bringen eigene Fehler mit.

SSH-2 wurde in einer IETF-Arbeitsgruppe namens secsh ausgearbeitet und im Januar 2006 als RFCs veröffentlicht: die Architektur in RFC 4251, die Transportschicht in RFC 4253, die Benutzerauthentifizierung in RFC 4252 und die Verbindungsschicht in RFC 4254. Die Aufteilung in Schichten ist der entscheidende Punkt, weil dadurch jede Schicht unabhängig ersetzt werden kann. Der größte Teil dieser weiteren Entwicklung besteht aus solchen Ersetzungen.

Zwei Änderungen sind besonders wichtig. Die Integritätssicherung wechselte von CRC-32 zu einem HMAC (hash-based message authentication code), der mit einem gemeinsamen Geheimnis geschützt wird. Ein Angreifer, der den MAC nicht berechnen kann, kann daher kein Paket fälschen. Außerdem wechselte der Schlüsselaustausch zu Diffie-Hellman. Bei SSH-1 wählte der Client den Sitzungsschlüssel und sendete ihn, verschlüsselt mit dem RSA-Schlüssel des Servers. Wer später in den Besitz des privaten Schlüssels gelangte, konnte dadurch eine aufgezeichnete Sitzung entschlüsseln. Diffie-Hellman leitet für jede Sitzung ein neues Geheimnis ab, das niemals übertragen wird. Wer heute den Netzwerkverkehr aufzeichnet und später den Host-Schlüssel stiehlt, kann daraus daher nichts gewinnen. Diese Eigenschaft wird Forward Secrecy genannt.

SSH-2 ist auf der Leitungsebene nicht mit SSH-1 kompatibel. Deshalb wurde die Nummer geändert und nicht nur die Dezimalzahl erhöht.

Warum SSH-1 entfernt und nicht repariert wurde

Die Entfernung erfolgte über drei OpenSSH-Releases. Version 7.0 deaktivierte Protokoll 1 am 11. August 2015 standardmäßig bereits zur Compile-Zeit. Version 7.4 entfernte am 19. Dezember 2016 die Serverunterstützung dafür. Version 7.6 entfernte am 3. Oktober 2017 auch die Clientseite sowie die zugehörigen Konfigurationsoptionen und die Dokumentation.

Für alte Geräte wäre es benutzerfreundlicher gewesen, die Funktion als Option beizubehalten. Der CRC-32-Detektor erklärt jedoch, warum diese Möglichkeit abgelehnt wurde. Der Overflow war nur erreichbar, weil der Code für Protokoll 1 einkompiliert war. Außerdem befand er sich in einem Codepfad, den die meisten Administratoren auf ihren Systemen für inaktiv hielten. Ausgelieferter Code kann erreicht werden. Gelöschter Code nicht.

Warum Ihre erste SSH-Verbindung vor dem Hostschlüssel warnt

Verschlüsselung stellt sicher, dass der Netzwerkverkehr privat bleibt. Sie sagt jedoch nicht, wer sich am anderen Ende befindet. Wenn ein Angreifer die Verbindung abfängt und anstelle Ihres Servers antwortet, erhalten Sie eine vollständig verschlüsselte Sitzung mit dem Angreifer. Das ist ein Machine-in-the-Middle-Angriff. SSH begegnet diesem Problem mit einem Hostschlüssel: Der Server weist nach, dass er über die private Hälfte eines Schlüsselpaares verfügt, und der Client vergleicht diesen Schlüssel mit dem zuletzt gespeicherten Wert. Wenn Sie die Mechanismen des Verbindungsaufbaus selbst nachvollziehen möchten, lesen Sie was beim Öffnen einer SSH-Verbindung geschieht.

Beim ersten Verbindungsaufbau gibt es keinen vorherigen Wert. Der Client kann daher nichts vergleichen und muss Sie fragen:

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])?

Wenn Sie mit yes antworten, wird dieser Schlüssel in ~/.ssh/known_hosts gespeichert. Bei jeder späteren Verbindung wird er mit dem gespeicherten Wert verglichen. Bei einer Abweichung gibt das Programm seine deutlichste Warnung aus:

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

Die ehrliche Bedeutung dieser ersten Abfrage ist, dass das Protokoll seinen einzigen schwachen Moment offenlegt. Trust on First Use bedeutet, dass die erste Verbindung nur so sicher ist wie das Netzwerk, über das sie hergestellt wurde. Diese Lücke lässt sich schließen. Lesen Sie den Fingerabdruck aus der Konsole Ihres Providers oder aus dem Build-Log des Servers, bevor Sie die Verbindung herstellen. Veröffentlichen Sie ihn als SSHFP-Eintrag in DNS (RFC 4255). Das ist allerdings nur sinnvoll, wenn Sie DNSSEC einsetzen. Oder signieren Sie Hostschlüssel mit Ihrer eigenen Zertifizierungsstelle (CA), sodass die Clients der CA und nicht jedem einzelnen Schlüssel vertrauen. In der Praxis akzeptieren die meisten Personen die Abfrage, ohne sie zu prüfen. Das sollte man offen benennen.

Wie öffentliche Schlüssel Passwörter verdrängten

Die Authentifizierung mit öffentlichen Schlüsseln war bereits in den frühen SSH-Releases verfügbar. Trotzdem dauerte es Jahre, bis sie zum normalen Standard wurde. Der Mechanismus ist asymmetrisch: Der Client weist durch die Signatur einer Challenge nach, dass er den privaten Schlüssel besitzt. Der private Schlüssel verlässt den Client nie. Bei einem Passwort ist es umgekehrt. Auch wenn SSH das Passwort innerhalb des verschlüsselten Kanals überträgt, erhält der Server das eigentliche Geheimnis. Ein kompromittierter oder bösartiger Server besitzt damit etwas, das er an anderer Stelle gegen Sie verwenden kann.

Der zweite Grund ist die Mathematik. Jeder Server mit einem offenen Port 22 an einer öffentlichen Adresse erhält rund um die Uhr automatisierte Anmeldeversuche, und ein Passwort ist eine erratbare Zeichenfolge. Ein Schlüssel ist praktisch nicht erratbar. Mit PasswordAuthentication no beenden Sie diese gesamte Angriffskategorie. Deshalb steht diese Einstellung auf jeder Hardening-Checkliste. Gleichzeitig entfällt der Fallback, der Sie früher gerettet hat, wenn ein Schlüssel nicht funktionierte. Lernen Sie daher, die verschiedenen Fehler zu unterscheiden, die alle Permission denied (publickey) melden, bevor Sie selbst ausgesperrt sind. Ohne Passwörter zu arbeiten bedeutet außerdem, dass sich mehrere Schlüssel ansammeln. Ein Agent, der ein Dutzend Schlüssel hält, bietet sie nacheinander an, bis der Server sein Versuchslimit erreicht und die Verbindung beendet. Deshalb kann eine Anmeldung mit Too many authentication failures fehlschlagen, obwohl der richtige Schlüssel geladen ist. Das Erzeugen und Austauschen von Schlüsseln wird in Grundlagen der SSH-Schlüsselverwaltung behandelt. Die serverseitigen Einstellungen finden Sie unter SSH auf einem VPS härten.

Warum sich die Liste der SSH-Algorithmen ständig ändert

Ein geschichtetes Protokoll ermöglicht es, Algorithmen außer Betrieb zu nehmen, ohne ein neues Protokoll zu benötigen. OpenSSH nutzt diese Möglichkeit konsequent. Die Veröffentlichungsdaten zeigen, wie schnell dies geschieht.

Ed25519 wurde am 30. Januar 2014 mit OpenSSH 6.5 eingeführt, zusammen mit der Chiffre chacha20-poly1305 und einem durch bcrypt geschützten Format für private Schlüssel. Ed25519-Signaturen leiten ihre Nonce für jede Signatur deterministisch ab. Ein schwacher Zufallszahlengenerator zum Zeitpunkt der Signatur kann den privaten Schlüssel daher nicht offenlegen. Genau auf diese Weise wurden private DSA- und ECDSA-Schlüssel bei realen Sicherheitsvorfällen ermittelt.

Bei DSA verlief die Entwicklung umgekehrt. OpenSSH 7.0 deaktivierte ssh-dss-Host- und Benutzerschlüssel 2015 zur Laufzeit, weil der Algorithmus auf einen 160-Bit-Privatschlüssel und SHA-1 beschränkt ist. Version 9.8 deaktivierte DSA am 1. Juli 2024 zur Compile-Zeit. Version 10.0 entfernte DSA am 9. April 2025. In den Worten des Projekts wurde damit „der 2015 begonnene Abschaffungsprozess abgeschlossen“. Zehn Jahre von der Deaktivierung bis zur Entfernung.

RSA wurde nicht entfernt, aber sein altes Signaturformat schon. OpenSSH 8.8 akzeptiert seit dem 26. September 2021 standardmäßig keine RSA-Signaturen mehr, die mit SHA-1 erstellt wurden. Die Release Notes nennen den Grund ausdrücklich: SHA-1 ist kryptografisch gebrochen, und Kollisionen mit frei wählbarem Präfix waren für weniger als 50.000 USD möglich. Wenn Ihnen sign_and_send_pubkey: no mutual signature supported beim Verbinden mit einem alten Server begegnet ist, handelt es sich um diese Änderung. Ihr Schlüssel ist in Ordnung. Der Signaturalgorithmus, den die Gegenstelle angefordert hat, ist es nicht.

Derselbe Prozess läuft jetzt beim Schlüsselaustausch ab, diesmal im Vorgriff auf die Bedrohung. Heute aufgezeichneter Netzwerkverkehr kann gespeichert und Jahre später von derjenigen Partei entschlüsselt werden, die zuerst über einen leistungsfähigen Quantencomputer verfügt. Deshalb musste sich der Schlüsselaustausch ändern, bevor eine solche Maschine existiert. OpenSSH 9.0 machte am 8. April 2022 einen hybriden Schlüsselaustausch zum Standard: sntrup761x25519-sha512@openssh.com kombiniert einen Post-Quantum-Algorithmus mit dem X25519-Schlüsselaustausch. Das Ergebnis ist dadurch nicht schwächer als der klassische Teil, falls der neue Algorithmus sich als unzureichend erweist. OpenSSH 9.9 fügte am 19. September 2024 mlkem768x25519-sha256 hinzu. Dieser Algorithmus basiert auf ML-KEM (module lattice key encapsulation mechanism), das NIST 2024 standardisiert hat. OpenSSH 10.0 machte ihn zum Standard für den Schlüsselaustausch. Die Post-Quantum-Seite des Projekts erläutert die Gründe. OpenSSH 10.1 begann am 6. Oktober 2025 mit einer Warnung, sobald eine Verbindung einen Schlüsselaustausch aushandelt, der nicht Post-Quantum-fähig ist:

** 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.

Diese Warnung ist standardmäßig aktiviert und wird durch die Option WarnWeakCrypto in ssh_config gesteuert. Beide hybriden Verfahren gelten als Post-Quantum-Verfahren. Ein Server, der noch den älteren Standard sntrup761 verwendet, löst die Warnung daher nicht aus. OpenSSH 10.6 fügte dieselbe Option am 6. Oktober 2026 zu sshd_config hinzu. Auch dort ist sie standardmäßig aktiviert und protokolliert Clients, die sich ohne Post-Quantum-Schlüsselaustausch verbinden. Die Standardwerte für den Post-Quantum-SSH-Schlüsselaustausch erläutern, was die Warnung in der Praxis bedeutet und wie Sie mit einem Server umgehen, der sie auslöst. Die Warnung verweist selbst auf den Server. Eine KexAlgorithms-Zeile in der Konfiguration Ihres eigenen Clients kann die Post-Quantum-Optionen jedoch genauso wirksam ausschließen. Prüfen Sie daher welchen Schlüsselaustausch Ihre Verbindung tatsächlich ausgehandelt hat, bevor Sie etwas aktualisieren.

Was diese Geschichte für den Server vor Ihnen bedeutet

Der Befehl, den Sie eingeben, hat sich seit 1995 kaum verändert. Fast alles darunter wurde ersetzt: die Integritätsprüfung, der Schlüsselaustausch, die Signaturalgorithmen und die Codebasis selbst. Das war nur möglich, weil jede Ersetzung mit einer gezielten Entfernung endete. Jede Entfernung führte für einige Anwender zu Problemen.

Die Sicherheit Ihrer SSH-Verbindung wird daher hauptsächlich durch Ihre Version bestimmt. Die Standardwerte enthalten die Entscheidungen darüber, welche Algorithmen angeboten, abgelehnt und mit welchen Warnungen angezeigt werden. Ein alter Server bietet weiterhin alles an, was sein Release noch zulässt. Eine Verbindung verwendet dann das, was beide Seiten noch erlauben. Wenn keine gemeinsamen Algorithmen vorhanden sind, schlägt sie vollständig fehl. Im Oktober 2026 ist OpenSSH 10.6 die aktuelle Version. Sie wurde am 6. Oktober 2026 veröffentlicht. Der Abstand zwischen dieser Version und der Version auf einer Maschine, die seit drei Jahren niemand gewartet hat, zeigt das Ausmaß des Problems. Die Prüfung gehört in die ersten zehn Minuten auf einem neuen VPS.

FAQ

Wer hat SSH entwickelt und warum?

Tatu Ylönen, ein Forscher an der Helsinki University of Technology, entwickelte SSH 1995 nach einem Angriff, bei dem Passwörter im Universitätsnetzwerk mitgeschnitten wurden. Die damaligen Tools für Remote-Logins, telnet und rlogin, übertrugen Passwörter als lesbaren Text über das Netzwerk. Jeder, der ein gemeinsam genutztes Netzwerksegment überwachte, konnte die Zugangsdaten beim Vorbeilaufen erfassen. Im Juli 1995 veröffentlichte er das Programm als Freeware. Ende desselben Jahres hatte es ungefähr 20,000 Benutzer in fünfzig Ländern. Im Dezember 1995 gründete er SSH Communications Security.

Was ist der Unterschied zwischen SSH-1 und SSH-2?

Es handelt sich um unterschiedliche Protokolle ohne Kompatibilität auf der Leitungsebene. SSH-1 war ein einzelnes monolithisches Protokoll. Es verwendete CRC-32 zur Integritätsprüfung und ließ den Client einen Sitzungsschlüssel senden, der mit dem RSA-Schlüssel des Servers verschlüsselt war. SSH-2 teilt die Aufgaben in eine Transport-, eine Authentifizierungs- und eine Verbindungsschicht auf (RFCs 4251 bis 4254, Januar 2006). Es verwendet für die Integritätsprüfung einen HMAC und leitet Sitzungsschlüssel mit Diffie-Hellman ab. Dadurch bleibt aufgezeichneter Netzwerkverkehr vertraulich, selbst wenn der Hostschlüssel später gestohlen wird. SSH-1 wurde schrittweise aus OpenSSH entfernt. Dieser Prozess endete mit Version 7.6 im Oktober 2017.

Warum ersetzte OpenSSH die ursprüngliche SSH-Implementierung?

Die Entwicklung der ursprünglichen Implementierung ging in ein kommerzielles Produkt mit einer restriktiven Lizenz über. Die letzte frei wiederverwendbare Version war ssh 1.2.12. Anfang 1999 nahm Björn Grönvall diese Version als OSSH wieder auf. Das OpenBSD-Team erstellte daraus einen Fork namens OpenSSH. OpenSSH wurde am 1. Dezember 1999 mit OpenBSD 2.6 veröffentlicht. OpenBSD benötigte für sein Basissystem geprüften Code unter einer uneingeschränkten Lizenz. Diese beiden Eigenschaften ermöglichen es bis heute, dass jedes andere Betriebssystem dieselbe Implementierung über den portablen Entwicklungszweig veröffentlicht.

Warum fragt SSH beim ersten Verbindungsaufbau nach dem Hostschlüssel?

Der Client hat diesen Server zuvor noch nicht gesehen und kann seinen Schlüssel daher mit keinem gespeicherten Wert vergleichen. Eine Verschlüsselung allein kann keinen vertrauenswürdigen Server von einem Rechner unterscheiden, der sich zwischen Client und Server in den Übertragungsweg eingeschaltet hat. Deshalb identifiziert SSH Server anhand ihres Schlüssels und speichert den erkannten Wert in ~/.ssh/known_hosts. Beim ersten Verbindungsaufbau gibt es keinen gespeicherten Wert für die Prüfung. Deshalb fragt der Client Sie. Vergleichen Sie den Fingerabdruck mit einem Wert aus der Provider-Konsole oder vom Server selbst. Behandeln Sie jede spätere Meldung REMOTE HOST IDENTIFICATION HAS CHANGED als tatsächliches Ereignis, bis Sie die Änderung erklären können.

Warum funktionieren ältere SSH-Schlüssel nach einem Upgrade nicht mehr?

OpenSSH nimmt Algorithmen nach einem veröffentlichten Zeitplan außer Betrieb. DSA-Schlüssel (ssh-dss) wurden in OpenSSH 7.0 im Jahr 2015 standardmäßig deaktiviert und in OpenSSH 10.0 am 9. April 2025 vollständig entfernt. RSA-Schlüssel funktionieren weiterhin. Signaturen mit SHA-1 wurden jedoch in OpenSSH 8.8 im September 2021 standardmäßig deaktiviert. Beim Verbindungsaufbau mit einem alten Server erscheint dies als sign_and_send_pubkey: no mutual signature supported. Ein Ed25519-Schlüssel, der seit OpenSSH 6.5 im Januar 2014 verfügbar ist, vermeidet beide Probleme.