Post-Quantum-SSH auf Ubuntu: Was sich geändert hat

Was sich bei Post-Quantum-SSH geändert hat

Post-Quantum-SSH ist für die meisten Benutzer bereits aktiviert, ohne dass sie etwas konfigurieren mussten. Ein aktueller OpenSSH-Client, der mit einem aktuellen OpenSSH-Server kommuniziert, wählt standardmäßig einen hybriden Post-Quantum-Schlüsselaustausch. Dadurch bleibt der Sitzungsschlüssel gegen einen Angreifer geschützt, der Ihren Netzwerkverkehr heute aufzeichnet und erst in einigen Jahren entschlüsselt. Der Schutz ist real. Er ist jedoch enger gefasst, als die Bezeichnung „quantensicheres SSH“ vermuten lässt.

Zunächst zwei Begriffe. SSH (Secure Shell) ist das Protokoll, mit dem Sie sich bei einem Server anmelden. Der Schlüsselaustausch, meist als „kex“ bezeichnet, ist der erste Schritt jeder SSH-Verbindung: Beide Seiten vereinbaren ein gemeinsames Geheimnis. Dieses Geheimnis verschlüsselt anschließend die gesamte Kommunikation. Geändert hat sich der Schlüsselaustausch. Alles andere blieb unverändert.

Vertrauen Sie dieser Seite nicht, sondern führen Sie die Befehle aus

Jeder unten genannte Algorithmusname stammt aus einem Befehl, den Sie selbst ausführen können. Das ist beabsichtigt. Der Standard ändert sich mit jedem OpenSSH-Release. Deshalb nennt eine Anleitung von vor zwei Jahren möglicherweise einen Algorithmus, den Ihr System nicht mehr bevorzugt, ohne Sie darüber informieren zu können. Wenn Sie diese Befehle kennen, benötigen Sie keine Artikel zu diesem Thema mehr, auch diesen nicht.

Beginnen Sie mit den Funktionen, die Ihr Build unterstützt.

ssh -V
ssh -Q kex

ssh -V gibt eine Versionszeile aus, die mit OpenSSH_ beginnt, gefolgt vom Ubuntu-Paket-Suffix und der OpenSSL-Version. ssh -Q kex gibt einen Schlüsselaustauschalgorithmus pro Zeile aus. Ein Build mit Post-Quantum-Unterstützung enthält in dieser Liste Namen wie mlkem768x25519-sha256 und sntrup761x25519-sha512@openssh.com, neben klassischen Namen wie curve25519-sha256.

Was Ihr Build unterstützt, ist nicht dasselbe wie das, was es anbietet

Das ist der Unterschied, den die meisten Beiträge auslassen. ssh -Q kex beantwortet eine Frage: Was könnte dieses Binary leisten? Die für Sie relevante Frage beantwortet es nicht: Was wird diese Verbindung tatsächlich anbieten? Die beiden Listen unterscheiden sich. Genau diese Lücke führt dazu, dass veraltete Anleitungen noch immer Schaden verursachen.

ssh -G example.com | grep -i '^kexalgorithms'
sudo sshd -T | grep -i '^kexalgorithms'

ssh -G <host> gibt die effektive Konfiguration des Clients für diesen Host aus, nachdem ~/.ssh/config und /etc/ssh/ssh_config angewendet wurden. sshd -T führt dieselbe Prüfung für den Server durch. Jeder Befehl gibt genau eine kexalgorithms-Zeile in der Reihenfolge der Präferenzen aus. Der erste Name in dieser Zeile ist die erste Wahl der jeweiligen Seite. Diese Zeile wird tatsächlich über die Verbindung übertragen.

Diese Lücke ist nicht nur theoretischer Natur. OpenSSH 8.5, veröffentlicht am 2021-03-03, fügte sntrup761x25519-sha512@openssh.com hinzu und ließ es absichtlich in der Standardliste weg. Bei dieser Version zeigt ssh -Q kex den Algorithmus an, ssh -G dagegen nicht. Das bedeutet: Das Binary unterstützt einen Post-Quantum-Schlüsselaustausch, aber keine Verbindung fordert ihn jemals an.

Lesen Sie den Algorithmus aus, den Ihre Verbindung ausgehandelt hat

ssh -v example.com 2>&1 | grep 'kex: algorithm'

Zwischen einem aktuellen Client und einem aktuellen Server wird Folgendes ausgegeben:

debug1: kex: algorithm: mlkem768x25519-sha256

mlkem768x25519-sha256 ist ein hybrider Algorithmus. Er verwendet ML-KEM (module-lattice key encapsulation mechanism, standardisiert als FIPS 203) mit dem Parametersatz 768 zusammen mit elliptic curve Diffie-Hellman über X25519 und kombiniert beide Ausgaben im Sitzungsschlüssel.

Bei einem älteren Server sehen Sie möglicherweise stattdessen:

debug1: kex: algorithm: curve25519-sha256

Dieser Name enthält keinen Post-Quantum-Anteil. curve25519-sha256 ist elliptic curve Diffie-Hellman allein und wird von einem leistungsfähigen Quantencomputer gebrochen. Genau deshalb wurde der Standard geändert.

Eine Aushandlungsregel erklärt, warum ein einzelner alter Rechner eine Sitzung zurückhält. Der Client sendet seine Liste in bevorzugter Reihenfolge, der Server sendet seine eigene Liste, und ausgewählt wird der erste Name aus der Client-Liste, der auch auf dem Server vorhanden ist. Die Präferenz des Clients hat Vorrang. Daher bestimmt das ältere der beiden Enden, wie weit oben in der Liste die Aushandlung kommt. Durch das Upgrade Ihres Laptops wird keine Sitzung zu einem Server aktualisiert, der ML-KEM nicht kennt.

ssh -v ist auch über diese eine Zeile hinaus nützlich, weil dieselbe Ausgabe die Stelle ist, an der Sie einen Fehler „Permission denied (publickey)“ untersuchen, wenn eine Anmeldung vollständig abgewiesen wird.

Lassen Sie grep und ssh -v weg. Dann zeigt die Ausgabe den Rest der Aushandlung, einschließlich der Zeile, um die es im nächsten Abschnitt geht:

debug1: kex: host key algorithm: ssh-ed25519

Welche OpenSSH-Version machte den hybriden Schlüsselaustausch zum Standard

Die Upstream-Release Notes zeigen eine klare Abfolge. Die Daten sind wichtiger als die Versionsnummern, weil sie zeigen, wie lange dieser Mechanismus bereits unauffällig aktiv ist.

• 8.5, veröffentlicht am 2021-03-03, fügte sntrup761x25519-sha512@openssh.com hinzu und ließ es standardmäßig deaktiviert.
• 9.0, veröffentlicht am 2022-04-08, aktivierte es. In den Notes steht, dass OpenSSH standardmäßig „use the hybrid Streamlined NTRU Prime + x25519 key exchange method“ wird. In dieser Version wurde ein Post-Quantum-Schlüsselaustausch zum Normalfall.
• 9.9, veröffentlicht am 2024-09-19, fügte mlkem768x25519-sha256 als zweite Option hinzu. Dieselbe Version gab dem älteren Verfahren den bei der IANA registrierten Namen sntrup761x25519-sha512. Deshalb führen neuere Builds es unter beiden Bezeichnungen auf.
• 10.0, veröffentlicht am 2025-04-09, machte mlkem768x25519-sha256 zum Standard für die Schlüsselvereinbarung.
• 10.1, veröffentlicht am 2025-10-06, fügte eine Client-Warnung hinzu, wenn eine Verbindung einen Schlüsselaustausch ohne Post-Quantum-Anteil aushandelt. Gesteuert wird sie durch die Option WarnWeakCrypto in ssh_config. Sie ist standardmäßig aktiviert.

April 2022 ist das Datum, das Sie sich merken sollten. Jedes Maschinenpaar mit OpenSSH 9.0 oder neuer führt seitdem einen Post-Quantum-Schlüsselaustausch durch, ohne Konfiguration und ohne Hinweis für die Person, die ssh eingibt.

Welche Ubuntu-Version liefert es aus

Ubuntu friert eine OpenSSH-Version zum Release ein und portiert anschließend Sicherheitskorrekturen zurück, ohne die Versionsnummer zu ändern. Die verwendete Ubuntu-Version bestimmt daher den Standardalgorithmus. Prüfen Sie das System vor sich mit ssh -V, statt einer Liste zu vertrauen. Im August 2026 enthält das Archiv folgende Versionen:

• Ubuntu 22.04 LTS liefert 1:8.9p1 aus. Diese Version ist älter als der Standard ab 9.0. Eine Standardinstallation handelt daher curve25519-sha256 aus.
• Ubuntu 24.04 LTS liefert 1:9.6p1 aus. Diese Version ist neuer als 9.0 und älter als 9.9. Der Standard ist daher sntrup761x25519-sha512@openssh.com. ML-KEM ist nicht enthalten.
• Ubuntu 25.10 liefert 1:10.0p1 aus. Der Standard ist mlkem768x25519-sha256.
• Ubuntu 26.04 LTS liefert 1:10.2p1 aus. Der Standard ist mlkem768x25519-sha256. Verbindungen ohne Post-Quantum-Schutz werden als Warnung gemeldet.

Betrachten Sie ein reales Paar von Systemen. Ein Laptop mit 26.04 verbindet sich mit einem Server mit 24.04. Die erste Wahl des Clients, mlkem768x25519-sha256, ist nicht in der Liste des 9.6-Servers enthalten. Die nächste Post-Quantum-Wahl des Clients, die der Server unterstützt, ist sntrup761x25519-sha512@openssh.com. Diesen Namen meldet ssh -v. Der Schlüsselaustausch der Sitzung ist Post-Quantum-fähig, obwohl der Server mit einer 2024 veröffentlichten Version erstellt wurde. Niemand musste dafür etwas konfigurieren.

Beim Fall mit 22.04 ist es umgekehrt. Er zeigt genau, warum ssh -Q kex allein irreführend ist. OpenSSH 8.9 kennt den Namen sntrup761x25519-sha512@openssh.com. Deshalb führt ssh -Q kex auf diesem System den Namen auf. Der Standardvorschlag enthält ihn jedoch nicht. Die Aushandlung verwendet daher curve25519-sha256. Mit einem Client ab OpenSSH 10.1 wird dies ausdrücklich gemeldet:

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

Diese Warnung betrifft den Server, zu dem Sie eine Verbindung herstellen, nicht Ihren Client. Die Lösung besteht darin, den Server zu aktualisieren. Durch das Setzen von WarnWeakCrypto no wird die Meldung entfernt. An der Verbindung ändert sich dadurch nichts.

Warum Hybridbetrieb und was „jetzt sammeln, später entschlüsseln“ bedeutet

Die Bedrohung ist einfach. Ein Angreifer, der Ihren Netzwerkverkehr sehen kann, zeichnet die verschlüsselten Bytes heute auf und speichert sie. Heute kann er sie nicht lesen. Er bewahrt sie auf, bis ein ausreichend großer Quantencomputer existiert, der X25519 brechen kann. Dann liest er sie. Dieses Vorgehen heißt „harvest now, decrypt later“ oder „store now, decrypt later“. Der Angreifer braucht dafür heute keine besonderen Fähigkeiten. Er braucht Speicherplatz und Geduld.

Bei der Verschlüsselung besteht dieses Problem, bei Signaturen jedoch nicht. Diese Asymmetrie bestimmt alles Weitere. Ein aufgezeichneter Ciphertext bleibt so lange wertvoll, wie die darin enthaltenen Daten vertraulich bleiben müssen. Eine Signatur muss nur in dem Moment nicht fälschbar sein, in dem sie geprüft wird. Wenn jemand 2035 einen Signaturalgorithmus bricht, kann er sich 2035 als Server ausgeben. Er kann dadurch nicht nachträglich einen Login aus dem Jahr 2026 fälschen. Deshalb musste der Schlüsselaustausch zuerst angepasst werden. Die Signaturseite kann warten.

Hybridbetrieb bedeutet, dass beide Algorithmen ausgeführt werden und beide Ergebnisse in den Sitzungsschlüssel einfließen. Um das Geheimnis hinter mlkem768x25519-sha256 wiederherzustellen, muss ein Angreifer ML-KEM 768 und X25519 brechen. Diese Kombination ist bewusst gewählt: ML-KEM ist deutlich neuer als X25519 und war deutlich kürzer Angriffen durch Kryptanalytiker ausgesetzt. Eine Schwachstelle im neuen Algorithmus gefährdet daher nicht den Schutz, den Sie bereits hatten.

Was ist geschützt und was nicht

Der Schlüsselaustausch ist geschützt. Das gemeinsame Geheimnis, mit dem Ihre Sitzung verschlüsselt wird, stammt aus einem hybriden Austausch. Eine heute aufgezeichnete Sitzung wird daher nicht lesbar, sobald Quantencomputer verfügbar sind.

Der Hostschlüssel ist nicht geschützt. Die Zeile debug1: kex: host key algorithm: ssh-ed25519 bezeichnet eine klassische Signatur. Das gilt auch für rsa-sha2-512 und die ECDSA-Typen (elliptic curve digital signature algorithm). Ein Angreifer mit einem funktionsfähigen Quantencomputer könnte diese Signatur fälschen und Ihren Server imitieren. Das wäre jedoch nur während einer zu diesem zukünftigen Zeitpunkt aktiv aufgebauten Verbindung möglich, niemals gegen heute aufgezeichneten Datenverkehr.

Auch Ihr Anmeldeschlüssel ist nicht geschützt. Der Schlüssel in ~/.ssh/id_ed25519 verwendet dieselbe Art klassischer Signatur. Daher gilt dieselbe Begründung. In diesem Jahr wird dieser Schlüssel dadurch geschützt, wo er gespeichert ist und wer darauf zugreifen kann. Eine sensible SSH-Schlüsselverwaltung reduziert Ihr tatsächliches Risiko daher wesentlich stärker als jeder Algorithmenname auf dieser Seite.

Sie müssen in beiden Fällen nichts unternehmen, weil es keine Alternative gibt, auf die Sie umstellen könnten. OpenSSH hat angekündigt, dass die Unterstützung für Post-Quantum-Signaturen in einer zukünftigen Version erscheinen soll. Solange diese Version nicht veröffentlicht ist, verfügt OpenSSH über keinen Post-Quantum-Hostschlüsseltyp und keinen Post-Quantum-Benutzerschlüsseltyp. Auch ssh-keygen kann Ihnen keinen solchen Typ anbieten. Eine Anleitung, die Sie zum Erzeugen eines solchen Schlüssels auffordert, beschreibt Software, die noch nicht existiert.

TLS auf demselben Server ist eine separate Frage mit einer separaten Antwort. TLS (transport layer security) ist das Protokoll, das Ihr Webserver auf Port 443 verwendet. Es basiert auf einer anderen Codebasis und folgt einem anderen Zeitplan. Ein Upgrade von OpenSSH ändert daran nichts. Wenn Sie ein selbstsigniertes Zertifikat für einen privaten Dienst auf demselben VPS verwenden, werden dessen Signatur und Schlüsselaustausch durch OpenSSL und Ihren Webserver bestimmt. Bewerten Sie diesen Stack daher unabhängig davon.

Was ein verantwortungsvoller Administrator jetzt tut

Halten Sie OpenSSH aktuell und belassen Sie es dabei. Das ist tatsächlich die gesamte Strategie für dieses Problem. sudo apt update && sudo apt upgrade hält Sie auf der Version, die Ihre Ubuntu-Version bereitstellt. Der Wechsel auf eine neuere Ubuntu-Version bringt Sie auf ein neueres OpenSSH. Wenn Sie unbeaufsichtigte Sicherheitsupdates aktivieren, werden diese Patches installiert, ohne dass Sie daran denken müssen. OpenSSH aus dem Quellcode zu bauen, nur um einem Algorithmusnamen hinterherzulaufen, ist ein schlechter Kompromiss. Sie verzichten dadurch auf die Sicherheitsupdates der Distribution für den am stärksten exponierten Dienst auf dem Server. Wenn Sie den Quellcode trotzdem herunterladen, prüfen Sie den Download vor dem Build anhand der veröffentlichten Prüfsumme.

Schreiben Sie keine KexAlgorithms-Zeile von Hand. Das ist die eine Maßnahme, die die Situation zuverlässig verschlimmert. Ein Hardening-Leitfaden aus dem Jahr 2018 enthält eine Liste, die 2018 korrekt war. Wenn Sie diese Liste in sshd_config einfügen, ersetzen Sie damit die Standardliste, statt sie zu ergänzen. Jeder seitdem eingeführte Algorithmus ist nun ausgeschlossen. Ein Server, der mlkem768x25519-sha256 selbst ausgehandelt hätte, fällt dadurch unbemerkt auf das zurück, was in der festgelegten Liste übrig bleibt. Führen Sie sudo sshd -T | grep -i '^kexalgorithms' auf jedem Server aus, den Sie übernommen haben. Wenn diese Zeile kürzer ist als die Zeile auf einer frischen Installation derselben Version, hat jemand die Liste festgelegt.

Wenn Sie einen konkreten Grund haben, die Liste zu ändern, ergänzen Sie sie, statt sie zu ersetzen. OpenSSH interpretiert ein vorangestelltes + als Anhängen, ein vorangestelltes - als Entfernen und ein vorangestelltes ^ als Verschieben an den Anfang.

KexAlgorithms ^mlkem768x25519-sha256

Testen Sie die Datei, bevor Sie sich darauf verlassen. sudo sshd -t prüft die Konfiguration und gibt nichts aus, wenn sie gültig ist. Eine KexAlgorithms-Zeile mit einem Algorithmus, den der Build nicht enthält, verhindert den Start von sshd. Auf einem entfernten Server bedeutet das, dass Sie sich nicht erneut anmelden können. Lassen Sie deshalb während der Arbeit eine zweite Sitzung geöffnet. Wenn sich die Listen der beiden Seiten nicht mehr überschneiden, meldet der Client dies eindeutig:

Unable to negotiate with 203.0.113.10 port 22: no matching key exchange method found. Their offer: curve25519-sha256,ecdh-sha2-nistp256

Verstehen Sie Werbung mit dem Begriff „quantensicher“ als Aussage über eine einzelne Schicht. Wenn ein Anbieter ein Produkt als quantensicher bezeichnet, beschreibt er die jeweils genannte Schicht. Dabei handelt es sich meist um einen Schlüsselaustausch an irgendeiner Stelle. Fragen Sie nach dem Algorithmusnamen und dem Protokoll, für das er gilt. Für OpenSSH im August 2026 lautet die zutreffende Aussage, dass der Schlüsselaustausch ein hybrider, postquanten-sicherer Schlüsselaustausch ist, während die Signaturen klassisch bleiben. Jede weitergehende Aussage sollte mit einem Namen belegt werden, den Sie in der Ausgabe von ssh -Q kex finden können.

Erledigen Sie weiterhin die unspektakulären, aber wichtigen Aufgaben. Ein postquanten-sicherer Schlüsselaustausch schützt nicht vor einem erratbaren Passwort oder vor einem privaten Schlüssel, der auf einen Laptop kopiert wurde, der später gestohlen wird. Diese Ursachen führen tatsächlich zur Übernahme von Servern. Standardmäßiges SSH-Hardening auf einem VPS bleibt daher für die Sicherheit entscheidend. Wenn Ihnen die hier beschriebenen Aushandlungsschritte nicht vertraut waren, erklärt was SSH beim Verbindungsaufbau tut die Phasen, die diese Seite voraussetzt.

FAQ

Ist meine SSH-Verbindung bereits postquantenresistent?

Führen Sie ssh -v yourserver 2>&1 | grep 'kex: algorithm' aus und lesen Sie den ausgegebenen Namen. mlkem768x25519-sha256 und sntrup761x25519-sha512@openssh.com sind hybride postquantenresistente Schlüsselaustauschverfahren. curve25519-sha256, ecdh-sha2-nistp256 und jeder Name aus diffie-hellman-group sind klassische Verfahren. Beide Seiten benötigen eine Version, die einen postquantenresistenten Namen anbietet. Bei der Aushandlung wird die erste Auswahl des Clients verwendet, die der Server ebenfalls unterstützt. Daher bestimmt das ältere System die Obergrenze.

Welche OpenSSH-Version machte den postquantenresistenten Schlüsselaustausch zum Standard?

OpenSSH 9.0, veröffentlicht am 2022-04-08, machte sntrup761x25519-sha512@openssh.com zum standardmäßigen Schlüsselaustauschverfahren. OpenSSH 9.9, veröffentlicht am 2024-09-19, fügte mlkem768x25519-sha256 hinzu. OpenSSH 10.0, veröffentlicht am 2025-04-09, machte dieses Verfahren stattdessen zum Standard. OpenSSH 10.1, veröffentlicht am 2025-10-06, begann zu warnen, wenn eine Verbindung keines der beiden Verfahren aushandelt. Prüfen Sie mit ssh -Q kex und ssh -G <host>, wie sich Ihr eigener Build verhält. Ihre Ubuntu-Version bestimmt, welche dieser Optionen verfügbar ist.

Sollte ich einen postquantenresistenten SSH-Schlüssel erzeugen?

Nein, denn OpenSSH unterstützt keinen solchen Schlüsseltyp. Die bisherigen postquantenresistenten Erweiterungen betreffen den Schlüsselaustausch. Dafür benötigen Sie weder Schlüsseldateien noch eine Konfiguration. Hostschlüssel und Anmeldeschlüssel verwenden weiterhin klassische Signaturen wie Ed25519 und RSA. Das Upstream-Projekt hat angekündigt, dass postquantenresistente Signaturen in einer zukünftigen Version folgen werden. Verwenden Sie weiterhin einen Ed25519-Schlüssel und schützen Sie seinen Speicherort.

Warum warnt ssh, dass meine Verbindung nicht postquantenresistent ist?

OpenSSH 10.1 und neuer geben ** WARNING: connection is not using a post-quantum key exchange algorithm. aus, wenn der ausgehandelte Schlüsselaustausch keinen postquantenresistenten Anteil enthält. Die Warnung betrifft den Server, nicht Ihren Client. Ihr Client hat einen postquantenresistenten Namen angeboten, aber der Server hat keinen davon akzeptiert. Aktualisieren Sie OpenSSH auf dem Server. Prüfen Sie außerdem, ob jemand in dessen sshd_config eine KexAlgorithms-Zeile festgelegt hat, die moderne Namen ausschließt. Mit WarnWeakCrypto no wird die Meldung ausgeblendet. Die Verbindung bleibt dadurch jedoch genau so unsicher wie zuvor.