Post-Quantum-SSH unter 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. Niemand musste es konfigurieren. Ein aktueller OpenSSH-Client, der mit einem aktuellen OpenSSH-Server kommuniziert, verwendet 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 Jahre später 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 alle nachfolgenden Daten. Geändert hat sich der Schlüsselaustausch. Alles andere blieb unverändert.

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

Jeder unten genannte Algorithmusname stammt aus einem Befehl, den Sie selbst ausführen können. Das ist beabsichtigt. Der Standard ändert sich mit jeder OpenSSH-Version. Deshalb nennt eine Anleitung von vor zwei Jahren möglicherweise einen Algorithmus, den Ihr Rechner nicht mehr bevorzugt. Die Anleitung kann das nicht erkennen. 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. Danach folgen das Ubuntu-Paket-Suffix und die OpenSSL-Version. ssh -Q kex gibt einen Schlüsselaustauschalgorithmus pro Zeile aus. Bei einem Build mit Post-Quanten-Unterstützung finden Sie 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 das, was es anbietet

Das ist die Unterscheidung, die in den meisten Beiträgen fehlt. ssh -Q kex beantwortet eine Frage: Was könnte diese Binärdatei tun? Die für Sie wichtige Frage beantwortet es nicht: Was wird diese Verbindung tatsächlich anbieten? Die beiden Listen unterscheiden sich. In dieser Lücke richten alte Empfehlungen großen Schaden an.

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 macht dasselbe für den Server. Beide geben jeweils eine einzelne kexalgorithms-Zeile in Prioritätsreihenfolge aus. Der erste Name in dieser Zeile ist die erste Wahl der jeweiligen Seite. Diese Zeile wird über das Netzwerk übertragen.

Die Lücke ist nicht theoretisch. OpenSSH 8.5, veröffentlicht am 2021-03-03, fügte sntrup761x25519-sha512@openssh.com hinzu und ließ es bewusst aus der Standardliste weg. In dieser Version zeigt ssh -Q kex den Algorithmus an, ssh -G dagegen nicht. Das bedeutet: Die Binärdatei unterstützt einen Post-Quanten-Schlüsselaustausch, aber keine Verbindung fordert ihn jemals an.

Lesen Sie den ausgehandelten Algorithmus Ihrer Verbindung

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 (modulare gitterbasierte Schlüsselkapselung, standardisiert als FIPS 203) mit dem Parametersatz 768 zusammen mit dem elliptischen-Kurven-Diffie-Hellman-Verfahren X25519 und kombiniert beide Ausgaben zum Sitzungsschlüssel.

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

debug1: kex: algorithm: curve25519-sha256

Dieser Name enthält keinen Post-Quanten-Anteil. curve25519-sha256 ist ein eigenständiges elliptisches-Kurven-Diffie-Hellman-Verfahren, das von einem leistungsfähigen Quantencomputer gebrochen werden kann. Genau deshalb wurde der Standard geändert.

Eine Verhandlungsregel 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 Auswahl reicht. Durch ein Upgrade Ihres Laptops wird eine Sitzung zu einem Server, der ML-KEM nicht kennt, nicht automatisch aktualisiert.

Entfernen Sie grep und ssh -v. Dann zeigt die Ausgabe den restlichen Ablauf der Verhandlung 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 Release Notes des Upstream-Projekts zeigen eine klare Abfolge. Die Daten sind wichtiger als die Versionsnummern, weil sie zeigen, wie lange dies bereits unbemerkt läuft.

• 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 Release Notes steht, dass OpenSSH standardmäßig die „hybride Streamlined NTRU Prime + x25519-Schlüsselaustauschmethode“ verwendet. Mit 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. In derselben Version erhielt die ältere Methode ihren bei der IANA registrierten Namen sntrup761x25519-sha512. Deshalb führen neuere Builds sie 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. Die Warnung wird über die Option WarnWeakCrypto in ssh_config gesteuert und ist standardmäßig aktiviert.

April 2022 ist das entscheidende Datum. Jedes Maschinenpaar mit OpenSSH 9.0 oder neuer führt seitdem standardmäßig einen Post-Quantum-Schlüsselaustausch durch. Dafür waren keine Konfiguration und keine Ankündigung an die Person erforderlich, die ssh eingibt.

Welche Ubuntu-Version liefert es aus

Ubuntu legt eine OpenSSH-Version beim Release fest und portiert anschließend Sicherheitskorrekturen zurück, ohne die Versionsnummer zu ändern. Die eingesetzte Ubuntu-Version bestimmt daher den Standardalgorithmus. Prüfen Sie das jeweilige System mit ssh -V, statt einer Liste zu vertrauen. Im August 2026 enthält das Archiv diese Versionen:

• 22.04 LTS liefert 1:8.9p1 aus. Diese Version ist älter als die Standardeinstellung ab 9.0. Eine Standardinstallation handelt daher curve25519-sha256 aus.
• 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.
• 25.10 liefert 1:10.0p1 aus. Der Standard ist mlkem768x25519-sha256.
• 26.04 LTS liefert 1:10.2p1 aus. Der Standard ist mlkem768x25519-sha256, und Verbindungen ohne Post-Quanten-Schutz werden gemeldet.

Betrachten wir 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 Servers mit 9.6 enthalten. Die nächste Post-Quanten-Auswahl des Clients, die der Server unterstützt, ist sntrup761x25519-sha512@openssh.com. Diesen Namen meldet ssh -v. Der Schlüsselaustausch der Sitzung ist Post-Quanten-sicher, obwohl der Server 2024 erstellt wurde und niemand etwas konfiguriert hat.

Bei 22.04 ist es umgekehrt. Dieser Fall zeigt genau, warum ssh -Q kex allein irreführend ist. OpenSSH 8.9 kennt den Namen sntrup761x25519-sha512@openssh.com. Daher führt ssh -Q kex auf diesem System den Namen auf. Der Standardvorschlag enthält ihn jedoch nicht, sodass die Aushandlung bei curve25519-sha256 endet. Mit einem OpenSSH-Client ab 10.1 wird dies angezeigt:

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

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

Warum Hybridverfahren und was „harvest now, decrypt later“ bedeutet

Die Bedrohung ist einfach. Ein Angreifer, der Ihren Datenverkehr 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 leistungsfähiger Quantencomputer existiert, der X25519 brechen kann. Dann liest er sie. Dieses Vorgehen wird als „harvest now, decrypt later“ oder „store now, decrypt later“ bezeichnet. Der Angreifer benötigt dafür heute keine besonderen Fähigkeiten. Er braucht Speicherplatz und Geduld.

Dieses Problem betrifft die Verschlüsselung, nicht jedoch Signaturen. Diese Asymmetrie bestimmt alle weiteren Schritte. Ein aufgezeichneter Ciphertext bleibt so lange wertvoll, wie die darin enthaltenen Daten vertraulich bleiben müssen. Eine Signatur muss nur zum Zeitpunkt ihrer Prüfung nicht fälschbar sein. Wenn jemand im Jahr 2035 einen Signaturalgorithmus bricht, kann er sich im Jahr 2035 als Server ausgeben. Er kann dadurch keine Anmeldung aus dem Jahr 2026 nachträglich fälschen. Deshalb musste zuerst der Schlüsselaustausch abgesichert werden. Die Signaturseite kann warten.

Hybrid bedeutet, dass beide Algorithmen ausgeführt werden und beide Ergebnisse in den Sitzungsschlüssel einfließen. Um das Geheimnis hinter mlkem768x25519-sha256 zu ermitteln, muss ein Angreifer ML-KEM 768 und X25519 brechen. Diese Kombination ist beabsichtigt: ML-KEM ist deutlich neuer als X25519 und war Angriffen durch Kryptanalytiker wesentlich kürzer ausgesetzt. Eine Schwachstelle im neuen Algorithmus gefährdet dadurch 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, wenn Quantencomputer verfügbar sind.

Der Hostschlüssel ist nicht geschützt. Die Zeile debug1: kex: host key algorithm: ssh-ed25519 benennt 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 zu diesem künftigen Zeitpunkt bei einer aktiven Verbindung imitieren. Gegen heute aufgezeichneten Datenverkehr wäre dies jedoch nicht möglich.

Auch Ihr Anmeldeschlüssel ist nicht geschützt. Der Schlüssel in ~/.ssh/id_ed25519 verwendet dieselbe Art klassischer Signatur. Daher gilt auch hier dieselbe Begründung. Was diesen Schlüssel in diesem Jahr schützt, ist sein Speicherort und die Frage, wer ihn lesen kann. Deshalb reduziert ein sinnvoller Umgang mit SSH-Schlüsseln Ihr tatsächliches Risiko deutlich stärker als jeder Algorithmusname 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 einem künftigen Release verfügbar sein wird. Bis dahin bietet OpenSSH weder einen Post-Quantum-Hostschlüsseltyp noch einen Post-Quantum-Benutzerschlüsseltyp. Auch ssh-keygen bietet Ihnen keinen solchen Typ an. Eine Anleitung, die Sie zur Erzeugung eines solchen Schlüssels auffordert, beschreibt Software, die noch nicht existiert.

TLS auf demselben Server ist eine separate Frage mit einer eigenen 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. Eine Aktualisierung von OpenSSH ändert daran nichts. Wenn Sie ein selbstsigniertes Zertifikat für einen privaten Dienst auf demselben VPS verwenden, werden seine Signatur und sein Schlüsselaustausch durch OpenSSL und Ihren Webserver bestimmt. Bewerten Sie diesen Stack daher unabhängig davon.

Was ein umsichtig vorgehender 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 ausliefert. Ein Wechsel auf eine neuere Ubuntu-Version bringt Sie auf ein neueres OpenSSH. Wenn Sie unbeaufsichtigte Sicherheitsaktualisierungen aktivieren, werden diese Patches eingespielt, ohne dass Sie daran denken müssen. OpenSSH aus dem Quellcode zu erstellen, nur um einem Algorithmusnamen hinterherzulaufen, ist ein schlechter Tausch. Sie verzichten damit bei dem am stärksten exponierten Dienst des Systems auf die Sicherheitsaktualisierungen der Distribution. Wenn Sie den Quellcode trotzdem herunterladen, prüfen Sie den Download vor dem Erstellen gegen die veröffentlichte 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 erweitern. Jeder seitdem eingeführte Algorithmus ist nun ausgeschlossen. Ein Server, der andernfalls selbstständig mlkem768x25519-sha256 ausgehandelt hätte, fällt 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 sie jemand festgelegt.

Wenn Sie einen konkreten Grund haben, die Liste zu ändern, erweitern 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 analysiert die Konfiguration und gibt nichts aus, wenn sie gültig ist. Eine KexAlgorithms-Zeile mit einem Algorithmus, den der Build nicht unterstützt, verhindert den Start von sshd. Auf einem entfernten System bedeutet das, dass Sie sich nicht wieder anmelden können. Lassen Sie daher 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 einer bestimmten 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 Post-Quantum-Verfahren und klassische Verfahren kombiniert, während die Signaturen klassisch bleiben. Eine 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 Maßnahmen. Ein Post-Quantum-Schlüsselaustausch schützt nicht vor einem erratbaren Passwort und auch nicht vor einem privaten Schlüssel, der auf einen Laptop kopiert wurde, der später gestohlen wird. Diese Dinge führen in der Praxis tatsächlich zur Übernahme von Servern. Das standardmäßige 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 postquanten-sicher?

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 postquanten-sichere Schlüsselaustauschverfahren. curve25519-sha256, ecdh-sha2-nistp256 und alle Namen mit diffie-hellman-group sind klassische Verfahren. Beide Seiten benötigen eine Version, die einen postquanten-sicheren 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 postquanten-sicheren 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 keine der beiden Seiten ein postquanten-sicheres 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 sind.

Sollte ich einen postquanten-sicheren SSH-Schlüssel erzeugen?

Nein, denn OpenSSH unterstützt keinen solchen Schlüsseltyp. Die bisherigen postquanten-sicheren 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 postquanten-sichere 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 postquanten-sicher ist?

OpenSSH 10.1 und neuer geben ** WARNING: connection is not using a post-quantum key exchange algorithm. aus, wenn der ausgehandelte Schlüsselaustausch keine postquanten-sichere Komponente enthält. Die Warnung betrifft den Server, nicht Ihren Client. Ihr Client hat einen postquanten-sicheren 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 genauso schwach wie zuvor.