Post-Quanten-SSH: mlkem768x25519-sha256 in OpenSSH

OpenSSH unterstützt bereits heute eine Post-Quanten-Schlüsselvereinbarung, ohne zusätzliche Bibliothek und ohne Patch. Die hybride Methode mlkem768x25519-sha256 wurde mit OpenSSH 9.9 (19. September 2024) eingeführt und ist seit OpenSSH 10.0 (9. April 2025) die Standard-Schlüsselvereinbarung. Dieser Leitfaden zeigt, wie Sie ablesen, welche Methode eine Sitzung tatsächlich ausgehandelt hat, wie Sie die hybride Methode auf Builds bevorzugen, die sie unterstützen, aber nicht standardmäßig verwenden, was die Warnung von OpenSSH 10.1 zu nicht post-quantensicherer Schlüsselvereinbarung bedeutet und warum SSH-Hostschlüssel weiterhin klassisch sind.

Was mlkem768x25519-sha256 tatsächlich leistet

Der Name beschreibt die Konstruktion: ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, ein KEM bzw. Schlüsselkapselungsverfahren) mit dem Parametersatz 768, X25519 (Elliptische-Kurven-Diffie-Hellman auf Curve25519) und SHA-256 als Hashfunktion. Das NIST hat ML-KEM am 13. August 2024 als FIPS 203 veröffentlicht (FIPS 203); die Referenzseite zu ML-KEM listet die Parametersätze und den Status auf.

Die Methode ist hybrid: Der Sitzungsschlüssel wird sowohl aus dem gemeinsamen Geheimnis von ML-KEM als auch aus dem gemeinsamen Geheimnis von X25519 abgeleitet. Ein Client und ein Server, die diese Methode aushandeln, sind geschützt, solange mindestens eine der beiden Komponenten standhält. Das ist die konservative Wahl, solange Post-Quanten-Implementierungen noch jung sind, und genau darauf verweisen die europäischen Empfehlungen: hybride Schlüsselvereinbarung statt eines reinen Post-Quanten-Austauschs.

Die Schlüsselvereinbarung hat bei SSH aus demselben Grund Vorrang wie bei TLS. Ein Angreifer, der heute eine verschlüsselte Sitzung aufzeichnet, kann sie speichern und später angreifen. Dieses Vorgehen heißt Harvest now, decrypt later (HNDL) und wird in unserem Artikel zu Harvest now, decrypt later beschrieben. War der Austausch rein klassisch, könnte ein ausreichend großer Quantencomputer aufgezeichneten Datenverkehr nachträglich entschlüsseln. Bei der Authentifizierung ist das anders: Ein Angreifer, der eine Host-Signatur fälschen kann, muss dies während einer laufenden Verbindung tun. Die Migration der Signaturen kann daher später erfolgen, ohne die Sitzungen von gestern offenzulegen.

Schritt 1: Versionen prüfen und feststellen, was Ihre Sitzungen aushandeln

Welche Methoden unterstützt das Binary

ssh -V
ssh -Q kex
ssh -Q kex | grep mlkem

ssh -Q kex listet die in das Binary einkompilierten Schlüsselaustauschmethoden auf, unabhängig von der Konfiguration. Erscheint mlkem768x25519-sha256, unterstützt der Build die Methode. Beide Seiten müssen sie unterstützen, führen Sie dieselbe Prüfung also auch auf dem Server aus: Ein moderner Client, der mit einem alten Server kommuniziert, fällt auf das zurück, was beide gemeinsam haben.

Welche Methode hat diese Sitzung verwendet

ssh -v user@server 2>&1 | grep -i 'kex: algorithm'

Die ausführliche Ausgabe wird auf die Standardfehlerausgabe geschrieben, daher die Umleitung. Eine Sitzung mit der hybriden Methode gibt eine Zeile der Form debug1: kex: algorithm: mlkem768x25519-sha256 aus. Dies ist die mit Abstand nützlichste Prüfung, weil sie zeigt, was tatsächlich ausgehandelt wurde, und nicht, was Sie für konfiguriert halten.

Wie lautet die effektive Konfiguration

ssh -G server | grep -i kexalgorithms
sudo sshd -T | grep -i kexalgorithms

ssh -G gibt die Client-Konfiguration aus, die für dieses Ziel gelten würde, nachdem alle Host-Blöcke und Includes aufgelöst sind. sshd -T gibt die effektive Server-Konfiguration aus und erfordert Root-Rechte. Führen Sie beide Befehle aus, bevor Sie etwas ändern, und bewahren Sie die Ausgabe auf: Sie ist ein Nachweis für Ihr Inventar.

Die Versionshistorie

Quelle: die Release Notes von OpenSSH. Praktisch bedeutet das: Ab 9.9 steht Ihnen die Methode bereits zur Verfügung, ab 10.0 wird sie automatisch bevorzugt, und zwischen 9.0 und 9.9 verfügen Sie über sntrup761x25519-sha512@openssh.com dennoch über eine Post-Quanten-Schlüsselvereinbarung.

Schritt 2: mlkem768x25519-sha256 bevorzugen, ohne ältere Gegenstellen auszuschließen

Die maßgebliche Direktive ist KexAlgorithms, clientseitig in ssh_config und serverseitig in sshd_config. Sie akzeptiert drei Präfixe: ^ stellt die angegebenen Methoden an den Anfang der eingebauten Standardliste, + hängt sie an und - entfernt sie. Das Voranstellen ist der sichere Weg, weil der Rest der Standardliste als Rückfalloption erhalten bleibt.

Client, in ~/.ssh/config oder in einer Drop-in-Datei unter /etc/ssh/ssh_config.d/:

Host *
    KexAlgorithms ^mlkem768x25519-sha256

Server, in /etc/ssh/sshd_config oder in einer Drop-in-Datei unter /etc/ssh/sshd_config.d/:

KexAlgorithms ^mlkem768x25519-sha256

Wenn Sie eine explizite, geordnete Liste bevorzugen, setzen Sie die klassischen Methoden ans Ende, damit sich noch nicht aktualisierte Gegenstellen weiterhin verbinden können:

KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org

Validieren Sie die Konfiguration vor dem Neuladen, und laden Sie den Dienst neu, statt ihn neu zu starten:

sudo sshd -t
# the service name varies by distribution: ssh on Debian and Ubuntu, sshd on many others
sudo systemctl reload sshd

Eine Reihenfolge, die Aussperrungen vermeidet: Testen Sie zuerst in einer Staging-Umgebung, halten Sie während des Neuladens eine privilegierte Sitzung offen, öffnen Sie dann eine zweite Sitzung und wiederholen Sie die Prüfung mit ssh -v, bevor Sie die erste schließen. Entfernen Sie klassische Methoden erst dann aus der Serverliste, wenn jeder sich verbindende Client inventarisiert ist: Jump-Hosts, Automatisierungs-Runner, Backup-Agenten, Monitoring-Sonden, Netzwerkgeräte und eingebettete SSH-Bibliotheken sind hier die üblichen Ursachen für Ausfälle.

Schritt 3: die Warnung von OpenSSH 10.1 richtig deuten

OpenSSH 10.1 (6. Oktober 2025) warnt, wenn eine Verbindung eine nicht post-quantensichere Schlüsselvereinbarung aushandelt. Die Option heißt WarnWeakCrypto und ist standardmäßig aktiviert. Für den Betrieb sind zwei Punkte wichtig.

Erstens handelt es sich um eine Warnung, nicht um eine Durchsetzung: Die Verbindung kommt trotzdem zustande. Die Warnung zeigt Ihnen, dass die Gegenseite der Verbindung Aufmerksamkeit benötigt. Zweitens ist sntrup761x25519-sha512@openssh.com selbst ein hybrides Post-Quanten-Verfahren; eine Sitzung, die es aushandelt, ist also nicht der Fall, auf den diese Warnung abzielt. Es basiert lediglich nicht auf einem NIST-Standard, weshalb ML-KEM die Richtung für Interoperabilität und für Beschaffungsanforderungen vorgibt.

Behandeln Sie jede Warnung als eine Zeile in Ihrem Inventar: welche Gegenstelle, welche Version, welches Team verantwortlich ist. Wenn Sie klassische Austauschverfahren später ablehnen statt nur davor warnen möchten, legen Sie eine explizite KexAlgorithms-Liste an, die ausschließlich Post-Quanten-Methoden enthält, und tun Sie dies erst, wenn Ihre Prüfungen zeigen, dass jede Gegenstelle sie unterstützt.

Schritt 4: Hostschlüssel bleiben vorerst klassisch

Schlüsselvereinbarung und Authentifizierung werden in SSH getrennt ausgehandelt. Hostschlüssel und Benutzerschlüssel sind Signaturalgorithmen: ssh-ed25519, rsa-sha2-256, rsa-sha2-512 sowie ECDSA-Varianten. Die oben genannten Versionen haben die Schlüsselvereinbarung geändert, nicht die Hostschlüsseltypen. Der realistische Stand heute ist daher ein hybrider Austausch, der eine Sitzung schützt, die weiterhin mit einem klassischen Hostschlüssel authentifiziert wird. Welcher verwendet wurde, sehen Sie in derselben ausführlichen Ausgabe:

ssh -v user@server 2>&1 | grep -i 'host key'

Dieser Zwischenstand ist aus dem bereits genannten Grund vertretbar: Eine Signaturfälschung erfordert einen Angriff während der Verbindung und legt keine in der Vergangenheit aufgezeichneten Sitzungen offen. Das NIST hat ML-DSA am 13. August 2024 als FIPS 204 standardisiert (siehe die Seite zu ML-DSA); die Migration der SSH-Signaturen hängt von weiterer Arbeit an Protokoll und Implementierungen ab. Bis dahin sollten Sie die Lücke dokumentieren, statt sie zu verbergen, ed25519-Hostschlüssel bevorzugen und dort, wo RSA eingesetzt wird, die für Ihre Organisation geltenden Vorgaben zur Schlüssellänge befolgen.

Was Sie für Audits und Inventare dokumentieren sollten

SSH fehlt häufig in kryptografischen Inventaren, die TLS bereits sauber abdecken. Anforderung 12.3.3 von PCI DSS v4.0.1 verlangt, dass eingesetzte Cipher Suites und Protokolle dokumentiert und mindestens alle 12 Monate überprüft werden; sie ist seit dem 31. März 2025 verpflichtend (siehe PCI DSS v4.0.1). Im Rahmen von DORA verlangt Art. 6 der Delegierten Verordnung (EU) 2024/1774 der Kommission eine Richtlinie für Verschlüsselung und kryptografische Kontrollen, einschließlich Bestimmungen zur Aktualisierung oder Änderung kryptografischer Technologien auf Grundlage von Entwicklungen in der Kryptoanalyse, und Art. 7 verlangt ein Schlüsselmanagement über den gesamten Lebenszyklus (siehe die Seite zu den DORA-RTS). Wörtlich verlangen diese Texte die Richtlinie und das Inventar. Die folgende Zuordnung ist unsere Interpretation, wie sich dies für SSH nachweisen lässt, und kein Zitat einer Anforderung. Dies ist eine Information, keine Rechtsberatung.

Nächster Schritt: den Rest Ihrer Angriffsfläche prüfen

SSH ist ein Protokoll unter mehreren, und dieselbe hybride Konstruktion gibt es in TLS als X25519MLKEM768. Am schnellsten sehen Sie den Stand Ihrer öffentlichen Dienste, wenn Sie Ihre Domain mit PQC Status scannen: Der Scan zeigt die ausgehandelten Schlüsselaustauschgruppen, die TLS-Versionen und die Zertifikatskette. Kombinieren Sie dieses Ergebnis mit den obigen SSH-Prüfungen, eine Zeile pro Host, und Sie haben den Grundstein für ein echtes kryptografisches Inventar statt einer bloßen Annahme.