Wenn Sie diese Meldung schon einmal gesehen haben, wissen Sie vermutlich bereits, um welches Protokoll es in diesem Beitrag geht. Seit Oktober 2025 zeigt OpenSSH sie jedes Mal an, wenn ein Server keinen quantensicheren Schlüsselaustausch aushandeln kann. Die meisten Unternehmen nutzen SSH, um ihre Maschinen zu administrieren und Dateien zwischen ihnen zu übertragen. Genau diesen Traffic will ein Harvest-now-decrypt-later-Angreifer heute aufzeichnen.

OpenSSH bietet seit April 2022 standardmässig einen Post-Quantum-Schlüsselaustausch an. Vier Jahre später unterstützen die meisten Server noch immer keinen. Im Mai 2026 untersuchte Forescout 160 Millionen aus dem Internet erreichbare SSH-Server. Nur 12% davon unterstützten einen. Dieser dritte Beitrag unserer PQC-Serie behandelt beide Hälften der SSH-Migration, Schlüsselaustausch und Authentifizierung, und misst, was jede davon kostet.

Die Verschlüsselung funktioniert wie bei TLS. Client und Server vereinbaren ein gemeinsames Geheimnis und verschlüsseln dann alles mit einer symmetrischen Chiffre wie AES oder ChaCha20. Dieser Teil ist bereits quantensicher. Schlüsselaustausch und Signaturen sind es nicht. Mit einem kryptografisch relevanten Quantencomputer kann jeder, der eine Sitzung aufgezeichnet hat, das gemeinsame Geheimnis zurückgewinnen und die Sitzung entschlüsseln. Dieselbe Maschine kann auch Signaturen fälschen. Ein Angreifer kann sich so als Ihr Server ausgeben oder sich als einer Ihrer Benutzer anmelden.

SSH tauscht Schlüssel anders aus als TLS 1.3. Beide Seiten schicken zuerst eine KEXINIT-Nachricht mit den Algorithmen, die sie unterstützen, darunter jene für Schlüsselaustausch und «Host Key». Für jede Kategorie wird der erste Algorithmus auf der Liste des Clients gewählt, den auch der Server unterstützt. Erst danach schickt der Client seinen Teil des Schlüsselaustauschs. So sendet er nie einen Post-Quantum-«Key Share» an einen Server, der damit nichts anfangen kann.

OpenSSH 10.0 machte mlkem768x25519-sha256 zum Standard-Schlüsselaustausch, mit derselben Kombination aus X25519 und ML-KEM-768 wie bei TLS. Er ersetzte sntrup761x25519-sha512, seit 2022 der quantensichere Standard von OpenSSH, der aber kein NIST-Standard ist.

Die Signaturen folgten im Oktober 2026, als OpenSSH 10.6 den Algorithmus ssh-mldsa44-ed25519 aktivierte. Jede Signatur kombiniert eine ML-DSA-44-Signatur mit einer Ed25519-Signatur, und beide müssen gültig sein. Server können sie für ihre Host Keys verwenden, Benutzer für die Anmeldung.

Am teuersten sind die Signaturen, fast 40-mal so gross wie klassische. Bei TLS ist das ein echtes Problem: Der Server schickt eine ganze Zertifikatskette, und jedes Zertifikat enthält seinen eigenen öffentlichen Schlüssel und seine eigene Signatur. SSH verwendet standardmässig keine Zertifikatsketten. Jede Seite schickt einen Schlüssel und eine Signatur, der Mehraufwand bleibt also begrenzt. Deshalb sind Post-Quantum-Signaturen in SSH schon heute praxistauglich, während das Web noch auf Merkle Tree Certificates wartet.

Hybride Signaturen sind allerdings umstrittener als der hybride Schlüsselaustausch. Filippo Valsorda argumentierte, Composites brächten viel Komplexität für wenig Nutzen, da ML-DSA ausgereift genug sei, um allein zu bestehen. OpenSSH hat das Composite trotzdem ausgeliefert. Genau das werden Ihre Tools unterstützen, also sollten Sie es für SSH auch einsetzen.

Wir haben echte SSH-Anmeldungen zwischen demselben Client und Server gemessen, jedes Mal über denselben Netzwerkpfad. Grössen und Zeiten umfassen alles vom TCP-Handshake bis zu dem Moment, in dem der Benutzer angemeldet ist. Schlüsselaustausch und Signaturen migrieren unabhängig voneinander, deshalb haben wir sie getrennt gemessen.

Host Keys und Benutzerschlüssel bleiben Ed25519. Wir haben nur den hybriden Schlüsselaustausch auf jeder Seite umgeschaltet, was dieselben vier Konfigurationen ergibt wie in unserem TLS-Beitrag:

• Klassisch. Keine Seite unterstützt mlkem768x25519-sha256.
• Nur Client. Der Client bietet ihn an, der Server unterstützt ihn nicht.
• Nur Server. Umgekehrt.
• Beide PQC. Beide Seiten unterstützen ihn, und er wird auch ausgehandelt.

Der hybride Schlüsselaustausch fügt 2,6 KB hinzu und bringt den Handshake von 6,0 KB auf 8,6 KB. Das entspricht dem, was man von ML-KEM-Key-Share und -Ciphertext erwartet.

Wenn nur eine Seite das Hybridverfahren unterstützt, vermeidet SSH den Mehraufwand, den TLS in Kauf nimmt. Beide Seiten listen ihre Algorithmen in KEXINIT auf, bevor irgendjemand einen Key Share schickt. Ein PQC-Client sendet seinen 1,2-KB-Key-Share also nie an einen klassischen Server. Die einzigen zusätzlichen Bytes sind rund 80 B an Algorithmusnamen. Diese Vorsicht ist allerdings nicht gratis: Sie kostet SSH bei jeder Verbindung einen «Round Trip», ob mit PQC oder ohne, während TLS 1.3 seinen Key Share schon in der ersten Nachricht mitschickt. Für die PQC-Umstellung heisst das aber, dass Sie das Hybridverfahren auf Clients und Servern in beliebiger Reihenfolge aktivieren können, ohne dass in der Zwischenzeit jemand dafür bezahlt.

Die Zeit bewegt sich nicht. Auf einem guten Netzwerk liegen die vier Konfigurationen nur 3 ms auseinander, also im Messrauschen. Auch degradiertes Wi-Fi ändert daran nichts. Anders als TLS braucht SSH viele Round Trips, bis der Benutzer angemeldet ist, und jeder bringt seine eigene Verzögerung mit. Ein paar zusätzliche Millisekunden gehen da im Rauschen unter.

Mit aktiviertem hybridem Schlüsselaustausch haben wir die Schlüssel auf ssh-mldsa44-ed25519 umgestellt: zuerst den Benutzerschlüssel, dann den Host Key, dann beide. Die gemischten Fälle entsprechen einer echten Migration. Der Host Key ist der einfache Teil. Ein Admin erzeugt einen pro Server, und jeder aktuelle Client kann ihn prüfen, ohne selbst einen hybriden Schlüssel zu besitzen. Bei Benutzerschlüsseln dauert es länger, weil jeder Benutzer einen erstellen und auf jedem Server hinterlegen muss, auf dem er sich anmeldet.

Wird der Benutzerschlüssel auf ssh-mldsa44-ed25519 umgestellt, wächst der Handshake von 8,6 KB auf 15,3 KB. Mit hybridem Host Key sind es 14,0 KB, mit beiden 20,7 KB, also das 2,4-Fache der Grösse mit Ed25519-Schlüsseln.

Warum kostet ein Post-Quantum-Benutzerschlüssel mehr als ein Host Key? Jede Seite schickt nur eine Signatur, aber ihr öffentlicher Schlüssel geht mehrmals über das Netzwerk. Der Benutzerschlüssel wird vor der Anmeldung dreimal gesendet, der Host Key zweimal: einmal vom Server und einmal vom Client, um die Anmeldung an diesen Server zu binden. Eine dritte Kopie des Host Keys folgt direkt nach der Anmeldung, wenn der Server seine Host Keys teilt, damit der Client seine known_hosts aktualisieren kann. Da wir die Messung bei der Anmeldung beenden, ist sie hier nicht mitgezählt.

Auch die Zeit steigt. Post-Quantum-Schlüssel auf beiden Seiten verlängern den Handshake um etwa 10 ms auf einem guten Netzwerk und um 20 ms auf degradiertem Wi-Fi. Wie bei TLS kommt der Aufwand von den Paketen, nicht vom Rechenaufwand der Post-Quantum-Algorithmen. Jedes zusätzliche Paket gibt «Loss» und «Jitter» eine weitere Chance, die Anmeldung zu verzögern.

Die Signaturen können warten. Eine aufgezeichnete Sitzung lässt sich Jahre später entschlüsseln, eine gefälschte Signatur nützt einem Angreifer dagegen nur während einer laufenden Verbindung, und erst wenn ein Quantencomputer existiert. Die Migration der Signaturen ist aufwendiger. Admins müssen auf jedem Server einen hybriden Host Key erzeugen. Jeder Benutzer muss einen hybriden Schlüssel erzeugen, ihn auf jeder Maschine hinterlegen, auf der er sich anmeldet, und vor allem seine alten klassischen Schlüssel von diesen Servern löschen.

Dieses Aufräumen ist entscheidend. Anders als TLS-Zertifikate laufen SSH-Schlüssel standardmässig nicht ab. Ein einziger vergessener alter Schlüssel in authorized_keys genügt, damit sich ein Quantenangreifer auf Ihrer Maschine anmelden kann. Herauszufinden, welche Server noch einen klassischen Schlüsselaustausch aushandeln und welche Schlüssel noch herumliegen, beginnt mit einem kryptografischen Inventar.