PQC Quick Win 5: SSH auf hybriden Schlüsselaustausch umstellen

PQC Quick Win 5: SSH auf hybriden Schlüsselaustausch umstellen

SSH ist im KMU-Alltag die unsichtbare Hauptverkehrsader der Administration: Server-Zugriffe, Backup-Pipelines, Git-Pushes, Konfigurations-Management. Das Verfahren ist robust, aber sein Schlüsselaustausch nutzt bis heute oft klassisches Curve25519 oder NIST-P-Kurven – also genau die Klasse, die ein zukünftiger Quantencomputer in der Schlüsselableitung brechen würde. OpenSSH bietet seit Version 9 eine fertige Lösung: hybriden, quantenresistenten Schlüsselaustausch. Quick Win 5 schaltet sie scharf.

Was OpenSSH heute kann

Mit OpenSSH 9.0 (April 2022) wurde sntrup761x25519-sha512 zum Standard-Schlüsselaustausch – eine Kombination aus dem klassischen Curve25519 und dem post-quanten-Verfahren Streamlined NTRU Prime 761. Damit war OpenSSH der erste verbreitete Mainstream-Stack, der hybride PQC-Verfahren produktiv ausrollte. Inzwischen ist die Aufnahme von ML-KEM-768 in hybriden SSH-Codepoints (z. B. mlkem768x25519-sha256) in den jüngeren OpenSSH-Versionen erfolgt und wird die nächste Standardgeneration darstellen.

Das praktische Ergebnis: Aktueller Client gegen aktueller Server reden hybrid, ohne dass etwas getan werden muss. Trifft Aktuelles auf Altes, wird auf klassische Verfahren zurückgefallen.

Wo Sie typischerweise stehen

In KMU-Umgebungen sind drei Konstellationen üblich:

• Linux-Server mit Distributions-OpenSSH, der zur Version-Linie der jeweiligen Distribution gehört. Aktuelle Debian/Ubuntu/RHEL-Linien liefern eine OpenSSH-Version mit Hybrid-PQC bereits aktiv aus.
• Verwaltete Endgeräte mit OpenSSH-Client (Linux/macOS direkt, Windows über OpenSSH-for-Windows). Auch hier ist die Versionslage in den letzten zwei Jahren deutlich besser geworden.
• Embedded-Systeme, Storage-Appliances, Switche mit eigenständigem SSH-Stack. Das ist die kritische Klasse: Hier hängt PQC-Fähigkeit vom Hersteller und der Firmware ab.

So stellen Sie um

• OpenSSH-Versionen erheben: ssh -V auf einer Stichprobe Ihrer Server und Endgeräte. Ziel ist die Version, die hybride KEXe als Standard liefert.
• sshd_config setzen: Auf den Servern in /etc/ssh/sshd_config (oder Drop-in unter /etc/ssh/sshd_config.d/) eine explizite KEX-Reihenfolge eintragen:

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

  (Welche Codepoints konkret verfügbar sind, hängt von der OpenSSH-Version ab – ssh -Q kex zeigt die unterstützten Verfahren.)
• ssh_config setzen: Auf den Clients spiegelbildlich KexAlgorithms setzen.
• Konfiguration laden: sshd -t zur Syntax-Prüfung, anschließend systemctl reload sshd.
• Verifizieren: ssh -vv user@host aus einer Test-Session zeigt im Verbindungsaufbau das tatsächlich ausgehandelte KEX-Verfahren.
• Embedded-Geräte beim Hersteller anfragen: Roadmap-Auskunft einholen, in der Inventur dokumentieren.

Was sich am Risiko ändert

Der unmittelbare Effekt ist genau spiegelbildlich zur TLS-Welt: Sitzungsmitschnitte, die ein Angreifer heute aus Ihrem SSH-Verkehr aufzeichnet, lassen sich auch mit einem späteren Quantencomputer nicht mehr nachträglich entschlüsseln – sofern beide Enden hybriden Schlüsselaustausch sprechen. Schon eine klassische Strecke in der Mitte (Bastion-Host mit altem SSH, Embedded-Sprungbrett) hebelt diesen Schutz aus. Deshalb ist es wichtig, die Kette zu betrachten, nicht nur die Endpunkte.

Was Sie nicht damit erledigt haben

Quick Win 5 adressiert den Schlüsselaustausch. Die SSH-Hostschlüssel und die Benutzerschlüssel bleiben in dieser Phase typischerweise klassisch (Ed25519, RSA). Das ist konsistent mit dem aktuellen Stand der NIST- und BSI-Empfehlungen – Schlüsselaustausch hat in der “harvest now, decrypt later”-Logik die deutlich höhere Priorität als langlebige Signaturschlüssel. PQC-Hostschlüssel werden Thema einer späteren Etappe sein.

Was Sie diese Woche tun sollten

• ssh -V und ssh -Q kex auf den wichtigsten Servern und Client-Klassen ausführen.
• KexAlgorithms-Eintrag in sshd_config und ssh_config setzen, ohne klassische Verfahren ganz zu streichen – das wäre verfrüht.
• Verifikations-Session mit ssh -vv und Mitschnitt des ausgehandelten KEX im Change-Log dokumentieren.
• Bei Embedded-/Appliance-SSH den Hersteller mit einer kurzen, klaren Frage anschreiben: “Welche PQ-fähigen Schlüsselaustauschverfahren sind in Ihrer Firmware geplant, ab welcher Version?”
• Ergebnis in der Inventur-Tabelle eintragen.

Fazit

Hybrides PQC im SSH ist die geräuschloseste und gleichzeitig folgenreichste Aktivierung des Sprints. Aktuelles OpenSSH kann es ohnehin, in der Distribution ist es längst eingebaut, der Aufwand liegt im Bereich einer Tasse Kaffee. Wer SSH heute hybrid härtet, schließt eine der unauffälligsten Hintertüren des “harvest now, decrypt later”-Risikos.

Quellen

• OpenSSH – Release Notes (Default sntrup761x25519-sha512 ab OpenSSH 9.0) https://www.openssh.com/releasenotes.html
• OpenSSH – sshd_config Manpage https://man.openbsd.org/sshd_config
• IETF draft-josefsson-ntruprime-ssh – sntrup761 als SSH-KEX-Verfahren https://datatracker.ietf.org/doc/draft-josefsson-ntruprime-ssh/
• IETF draft-kampanakis-curdle-ssh-pq-ke – ML-KEM für SSH https://datatracker.ietf.org/doc/draft-kampanakis-curdle-ssh-pq-ke/

pqconsult: Ihre Partner bei der PQC-Migration

Wir helfen Ihnen, SSH konsistent über alle Server-, Client- und Sprungbrett-Klassen hinweg auf hybriden Schlüsselaustausch zu heben – inklusive Konfigurations-Templates für gängige Distributionen, Verifikations-Skripten und Roadmap-Bewertung für Appliance-Hersteller. Sprechen Sie uns an.