SSH-Geschichte: Von Telnet und rlogin zu OpenSSH

Wo die Geschichte von SSH beginnt

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

SSH war die Antwort einer einzelnen Person auf dieses Problem. Es wurde 1995 entwickelt und kostenlos bereitgestellt. Das Protokoll wurde seitdem einmal neu entwickelt. Das Programm, das heute fast alle verwenden, ist ein Fork eines Forks. Die folgenden Jahreszahlen sind wichtig, 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 übertragen. Jedes Gerät auf dem Übertragungsweg kann diese Bytes lesen.

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

Beide Entwürfe passten zu dem Netzwerk, für das sie entwickelt wurden. Frühes Ethernet war ein gemeinsam genutztes Übertragungsmedium: Jedes Gerät in einem Segment empfing jeden Frame und sollte Frames ignorieren, die nicht an das eigene Gerät adressiert waren. Ein Gerät, das diese Frames nicht mehr ignorierte, befand sich im Promiscuous Mode und konnte den Netzwerkverkehr aller anderen Geräte sehen. Wenn eine Universität zusätzlich Tausenden Studierenden Shell-Konten bereitstellte, wurde aus einem kompromittierten Konto ein Passwortsammler für ein ganzes Institut.

Der Sicherheitshinweis von 1994 ohne verfügbare Fehlerbehebung

Am 3. Februar 1994 veröffentlichte CERT den Sicherheitshinweis CA-94:01 mit dem Titel „Ongoing Network Monitoring Attacks“. Darin wurde berichtet, dass Angreifer Zugangsdaten für mehrere zehntausend 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 jedes über das Netzwerk erreichbaren Kontos 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 für eine Fehlerbehebung, weil keines der beiden Protokolle dafür einen vorgesehenen Mechanismus hatte.

Warum ein Sniffing-Angriff in Helsinki SSH hervorbrachte

1995 wurde das Netzwerk der Technischen Universität Helsinki von einem Passwort-Sniffing-Angriff der Art getroffen, die 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 bestätigte der Server seine Identität mit einem Schlüssel. Dadurch konnte der Client erkennen, ob er den richtigen Rechner erreicht hatte. Genau diese Lücke ließ das Vertrauen von rlogin in Hostnamen offen.

Die Software verbreitete sich auch, weil die Befehle den bereits verwendeten Befehlen entsprachen. ssh ersetzte rsh und rlogin, während scp rcp ersetzte. Der Wechsel erforderte eine neue Gewohnheit, aber keinen anderen Arbeitsablauf. Bis Ende 1995 war die Benutzerbasis auf ungefähr 20,000 Benutzer in fünfzig Ländern angewachsen. Im Dezember desselben Jahres 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äftsbereich wurde, änderte sich die Lizenz des Quellcodes. Spätere Veröffentlichungen enthielten Bedingungen, die einschränkten, was andere mit dem Code tun durften, und 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 weiterentwickelt wurde, während die Entwicklung an einem Ort fortgesetzt wurde, dem diese Welt nicht folgen konnte. Lizenzen entscheiden darüber, welcher Code fortbesteht – ein Muster, über das Sie in wie Open-Source-Lizenzen die moderne Infrastruktur geprägt haben mehr erfahren können.

Warum OpenBSD 1999 OpenSSH forkte

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

Das OpenBSD-Projekt übernahm OSSH und entwickelte es weiter. Nach Angaben des Projekts selbst bereinigten, prüften und erweiterten Theo de Raadt, Niels Provos, Markus Friedl, Bob Beck, Aaron Campbell und Dug Song den Code. Das Ergebnis war OpenSSH 1.2.2. Diese Version wurde am 1. Dezember 1999 mit OpenBSD 2.6 veröffentlicht.

Warum setzte sich der Fork eines kleinen Betriebssystemprojekts auf nahezu jedem Rechner durch? Der Grund waren die Anforderungen von OpenBSD. OpenBSD veröffentlicht ein geprüftes Basissystem, das in der Standardkonfiguration sicher sein soll. Daher musste die verschlüsselte Anmeldung aus der Ferne Bestandteil dieses Basissystems sein und unter einer Lizenz stehen, die keine Einschränkungen enthielt. 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 Versionsnummer 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 heute verwendeten Systemen erklärt, warum diese Anpassungen überhaupt erforderlich sind.

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

Warum SSH-2 ein neues Protokoll und keine Versionsänderung ist

SSH-1 schützte die Integrität des verschlüsselten Datenstroms mit CRC-32. Diese Prüfsumme war dafür ausgelegt, Übertragungsfehler zu erkennen, nicht dafür, einem Angreifer zu widerstehen. 1998 zeigten Ariel Futoransky und Emiliano Kargieman von CORE SDI, welche Folgen das hat. Bei den Verschlüsselungsmodi CBC oder CFB und einer CRC-32-Prüfung kann ein Angreifer, der nur 16 Byte des Klartexts kennt, manipulierten Chiffretext einschleusen, den der Empfänger als echt akzeptiert. Dadurch lassen sich Befehle auf dem Server ausführen.

Der Fehler lag im Protokoll und konnte daher nicht behoben werden, ohne die Kompatibilität zu brechen. Stattdessen lieferten die Implementierungen einen Erkennungsmechanismus aus. 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 die Remote-Codeausführung gegen Server und Clients möglich, die den Patch enthielten. 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 sich dadurch jede Schicht unabhängig ersetzen lässt. Der größte Teil der weiteren Entwicklung bestand 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 gebildet wird. Ein Angreifer, der den MAC nicht berechnen kann, kann dadurch kein gültiges 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 daher eine aufgezeichnete Sitzung entschlüsseln. Diffie-Hellman leitet für jede Sitzung ein neues Geheimnis ab, das niemals übertragen wird. Wenn der Netzwerkverkehr jetzt aufgezeichnet und der Hostschlüssel später gestohlen wird, lässt sich daraus nichts gewinnen. Diese Eigenschaft wird Forward Secrecy genannt.

SSH-2 ist auf der Leitung nicht mit SSH-1 kompatibel. Deshalb wurde die Nummer geändert und nicht nur die Dezimalstelle angepasst.

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 beim Kompilieren. Version 7.4 entfernte am 19. Dezember 2016 die Serverunterstützung dafür. Version 7.6 löschte am 3. Oktober 2017 auch die Clientseite sowie die zugehörigen Konfigurationsoptionen und die Dokumentation.

Eine Option für alte Geräte beizubehalten, wäre die benutzerfreundlichere Lösung gewesen. Der CRC-32-Detektor erklärt, warum diese Lösung abgelehnt wurde. Der Overflow war nur erreichbar, weil der Code für Protokoll 1 einkompiliert war. Außerdem lag er 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 Host-Key warnt

Die Verschlüsselung stellt sicher, dass der Netzwerkverkehr vertraulich ist. Sie bestätigt jedoch nicht, wer sich am anderen Ende befindet. Wenn ein Angreifer den Netzwerkpfad kontrolliert 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 Host-Key: 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 Wert, den er beim letzten Mal gespeichert hat. Wenn Sie die Abläufe beim Aufbau der Verbindung selbst nachvollziehen möchten, lesen Sie was beim Öffnen einer SSH-Verbindung geschieht.

Bei der ersten Verbindung gibt es kein letztes Mal. Der Client hat daher keinen Vergleichswert 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 erfolgt ein Vergleich mit dem gespeicherten Wert. 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 korrekte Einordnung dieser ersten Abfrage lautet: Das Protokoll weist auf seinen einzigen schwachen Moment hin. Trust on first use bedeutet, dass die Sicherheit der ersten Verbindung nur so hoch ist wie die Sicherheit des Netzwerks, über das Sie sie herstellen. 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-Record in DNS (RFC 4255). Das ist allerdings nur sinnvoll, wenn Sie DNSSEC einsetzen. Alternativ können Sie Host-Keys mit Ihrer eigenen Certificate Authority (CA) signieren. Dann vertrauen die Clients der CA und nicht jedem einzelnen Schlüssel. In der Praxis akzeptieren die meisten Benutzer 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 Standard wurde. Der Mechanismus ist asymmetrisch: Der Client weist durch das Signieren einer Challenge nach, dass er einen privaten Schlüssel besitzt. Der private Schlüssel verlässt den Client nie. Bei einem Passwort ist es umgekehrt. Obwohl 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 wiederverwenden kann.

Der zweite Grund ist mathematischer Natur. Jeder Server mit einem öffentlich erreichbaren Port 22 erhält rund um die Uhr automatisierte Anmeldeversuche. Ein Passwort ist eine erratbare Zeichenfolge. Ein Schlüssel ist praktisch nicht zu erraten. Das Setzen von PasswordAuthentication no beendet diese gesamte Angriffskategorie. Deshalb steht diese Maßnahme auf jeder Checkliste zur Absicherung. Das Erzeugen und Rotieren von Schlüsseln wird unter Grundlagen der SSH-Schlüsselverwaltung behandelt. Die serverseitigen Einstellungen finden Sie unter SSH auf einem VPS absichern.

Warum sich die SSH-Algorithmenliste ständig ändert

Ein geschichtetes Protokoll ermöglicht es, Algorithmen ohne ein neues Protokoll auslaufen zu lassen. OpenSSH nutzt diese Möglichkeit kontinuierlich, und die Veröffentlichungsdaten zeigen das Tempo.

Ed25519 wurde am 30. Januar 2014 in 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 während der Signaturerstellung kann deshalb den privaten Schlüssel nicht offenlegen. Genau so wurden private DSA- und ECDSA-Schlüssel bei realen Sicherheitsvorfällen wiederhergestellt.

Bei DSA verlief die Entwicklung in die andere Richtung. OpenSSH 7.0 deaktivierte ssh-dss Host- und Benutzerschlüssel 2015 zur Laufzeit, weil der Algorithmus auf einen privaten Schlüssel mit 160 Bit und auf 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 Ausmusterungsprozess abgeschlossen“. Zehn Jahre von der Deaktivierung bis zur Entfernung.

RSA verschwand nicht, 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 klar: 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 beim Verbinden mit einem alten Server schon einmal sign_and_send_pubkey: no mutual signature supported begegnet ist, handelt es sich um diese Änderung. Ihr Schlüssel ist in Ordnung. Der Signaturalgorithmus, den die andere Seite angefordert hat, ist es nicht.

Derselbe Prozess läuft jetzt beim Schlüsselaustausch, diesmal vorausschauend angesichts der Bedrohung. Heute aufgezeichneter Netzwerkverkehr kann von demjenigen gespeichert und Jahre später entschlüsselt werden, der zuerst über einen leistungsfähigen Quantencomputer verfügt. Deshalb musste sich die Schlüsselvereinbarung ändern, bevor eine solche Maschine existiert. OpenSSH 9.0 führte am 8. April 2022 einen hybriden Schlüsselaustausch als Standard ein: sntrup761x25519-sha512@openssh.com kombiniert einen Post-Quantum-Algorithmus mit dem X25519-Austausch. 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 Mechanismus basiert auf ML-KEM (module lattice key encapsulation mechanism), das NIST 2024 standardisiert hat. OpenSSH 10.0 machte ihn zum Standard für die Schlüsselvereinbarung. Die Post-Quantum-Seite des Projekts erläutert die Gründe. OpenSSH 10.1 begann am 6. Oktober 2025 zu warnen, wenn die andere Seite dies nicht unterstützt:

** 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. Was das in der Praxis bedeutet und wie Sie mit einem Server umgehen, der diese Warnung auslöst, wird in den Standardwerten für den Post-Quantum-SSH-Schlüsselaustausch beschrieben.

Was diese Entwicklung für den Server vor Ihnen bedeutet

Der eingegebene Befehl 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 bewussten Entfernung endete. Jede dieser Entfernungen führte bei jemandem zu Problemen.

Die Sicherheit Ihrer SSH-Verbindung wird daher größtenteils durch Ihre Version bestimmt. Die Standardeinstellungen enthalten die Entscheidungen darüber, welche Algorithmen angeboten und abgelehnt werden und welche Warnungen Sie sehen. Ein alter Server bietet weiterhin alles an, was seine Version noch zulässt, und handelt weiterhin auf einen älteren Standard herunter, um einen alten Client zu unterstützen. Im August 2026 ist OpenSSH 10.5 die aktuelle Version. Sie wurde am 11. August 2026 veröffentlicht. Der Abstand zwischen dieser Version und der Version auf einem Rechner, den seit drei Jahren niemand gewartet hat, zeigt die Größe des Problems. Die Prüfung gehört zu den 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 damals verwendeten Remote-Login-Tools telnet und rlogin übertrugen Passwörter als lesbaren Text über das Netzwerk. Jeder, der ein gemeinsam genutztes Netzwerksegment überwachte, konnte die Anmeldedaten 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. Der Client übertrug einen Sitzungsschlüssel, der mit dem RSA-Schlüssel des Servers verschlüsselt war. SSH-2 teilt die Aufgaben in eine Transportschicht, eine Authentifizierungsschicht und eine Verbindungsschicht auf (RFCs 4251 bis 4254, Januar 2006). Es verwendet einen HMAC zur Integritätsprüfung und leitet Sitzungsschlüssel mit Diffie-Hellman ab. Dadurch bleibt aufgezeichneter Netzwerkverkehr auch dann vertraulich, 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 hat OpenSSH die ursprüngliche SSH-Implementierung ersetzt?

Die Entwicklung der ursprünglichen Implementierung wurde in ein kommerzielles Produkt überführt, dessen Lizenz die Nutzung stark einschränkte. 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 ausgeliefert. OpenBSD benötigte für sein Basissystem geprüften Code unter einer uneingeschränkten Lizenz. Diese beiden Eigenschaften ermöglichten es allen anderen Betriebssystemen, über den portablen Zweig dieselbe Implementierung auszuliefern.

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

Der Client hat diesen Server zuvor noch nicht gesehen und kann seinen Schlüssel mit keinem gespeicherten Wert vergleichen. Eine Verschlüsselung allein kann einen vertrauenswürdigen Server nicht von einem Rechner unterscheiden, der sich zwischen den Kommunikationspartnern befindet. Deshalb identifiziert SSH Server anhand ihres Schlüssels und speichert den beobachteten Wert in ~/.ssh/known_hosts. Beim ersten Verbindungsaufbau gibt es noch keinen gespeicherten Wert für einen Vergleich. Deshalb fragt der Client Sie stattdessen. 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 echtes Ereignis, bis Sie die Ursache 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) waren in OpenSSH 7.0 im Jahr 2015 standardmäßig deaktiviert und wurden in OpenSSH 10.0 am 9. April 2025 vollständig entfernt. RSA-Schlüssel funktionieren weiterhin. Signaturen mit SHA-1 waren 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.