Linux

Wer sich aktuell mit SSH-Härtung beschäftigt, stolpert früher oder später über Begriffe wie Post-Quanten-Kryptografie, ML-KEM oder hybride Schlüsselaustauschverfahren. Gerade unter Debian 13 ist das Thema interessant, weil die Distribution bereits eine moderne OpenSSH-Version mitbringt und damit erste praktische Schritte in Richtung quantenresistenter Verbindungen erlaubt.

Wichtig ist dabei vor allem ein Punkt: Wenn von Post-Quanten-Keys gesprochen wird, ist im SSH-Umfeld häufig nicht der klassische Benutzer-Schlüssel für den Login gemeint, sondern der Schlüsselaustausch beim Verbindungsaufbau. Genau diese Unterscheidung ist entscheidend, denn unter Debian 13 ist davon schon ein Teil verfügbar, aber noch nicht alles.

In diesem Artikel schauen wir uns an, was unter Debian 13 mit OpenSSH bereits möglich ist, was noch nicht, wie man die aktive Kryptografie prüft und wann eine manuelle Konfiguration sinnvoll sein kann.

Was mit Post-Quanten-Keys bei SSH gemeint ist

Im Alltag werden mehrere Dinge oft in einen Topf geworfen:

der Benutzer-Schlüssel für die Anmeldung, zum Beispiel ED25519
der Host-Key des Servers
der Schlüsselaustausch beim Aufbau der SSH-Verbindung

Gerade der letzte Punkt ist für Post-Quanten-Kryptografie derzeit am wichtigsten.

Beim SSH-Login passiert zunächst ein kryptografischer Austausch, damit Client und Server einen gemeinsamen Sitzungsschlüssel aushandeln können. Dieser Sitzungsschlüssel schützt danach den restlichen Datenverkehr. Wenn ein Angreifer heute verschlüsselten Traffic mitschneidet und später einen leistungsfähigen Quantencomputer hätte, könnte ein rein klassischer Schlüsselaustausch in Zukunft problematisch werden. Genau dort setzen hybride Post-Quanten-Verfahren an.

Das bedeutet praktisch:

Dein ED25519-Login-Key ist nicht automatisch ein Post-Quanten-Key.
Der SSH-Kanal kann trotzdem schon gegen künftige Angriffe besser abgesichert sein.
Debian 13 bringt dafür bereits Unterstützung mit.

Warum das Thema überhaupt relevant ist

Die typische Sorge lautet: Ein echter Quantencomputer existiert für diesen Angriff doch noch gar nicht. Das stimmt zwar im praktischen Maßstab, aber genau deshalb wird das Thema jetzt relevant.

Das Risiko nennt sich oft store now, decrypt later:

Ein Angreifer zeichnet heute verschlüsselte Verbindungen auf.
Die Daten lassen sich im Moment nicht lesen.
Mit später verfügbarer Technik könnten alte Mitschnitte eventuell entschlüsselt werden.

Besonders relevant ist das bei:

langfristig sensiblen Admin-Zugängen
Infrastruktur mit langer Betriebsdauer
Backups und Archiven mit vertraulichen Daten
Verbindungen über fremde oder schlecht kontrollierbare Netze

SSH ist für Admin-Zugänge oft eines der wichtigsten Werkzeuge. Deshalb ist es sinnvoll, neue Schutzmechanismen früh zu nutzen, wenn sie stabil verfügbar sind.

Was Debian 13 konkret mitbringt

Debian 13 Trixie liefert OpenSSH 10.0p1. Das ist für dieses Thema wichtig, weil OpenSSH 10 den hybriden Post-Quanten-Schlüsselaustausch mlkem768x25519-sha256 standardmäßig bevorzugt.

Das ist keine Kleinigkeit, sondern der derzeit wichtigste praktische Fortschritt für SSH im Alltag:

ML-KEM liefert den Post-Quanten-Anteil.
X25519 bleibt als klassischer, etablierter Bestandteil erhalten.
Das Ergebnis ist ein hybrider Ansatz statt eines harten Komplettwechsels.

Der große Vorteil daran: Selbst wenn sich später bei einem der beiden Bausteine Probleme zeigen sollten, bleibt der kombinierte Ansatz robuster als ein übereilter Alleingang in nur eine Richtung.

Heisst das, dass ED25519 jetzt veraltet ist?

Nein. Das wäre die falsche Schlussfolgerung.

Unter Debian 13 ist ED25519 weiterhin eine sehr gute Wahl für:

Benutzer-Schlüssel
Host-Keys
allgemeine SSH-Authentifizierung

Der wichtige Unterschied ist nur:

ED25519 ist ein klassischer Signatur-Schlüssel.
mlkem768x25519-sha256 ist ein hybrides Verfahren für den Schlüsselaustausch.

Anders gesagt: Du kannst und sollst für deinen Login weiterhin ED25519 verwenden, während die eigentliche Verbindung bereits einen moderneren Austauschmechanismus nutzt.

Falls du den Login-Key selbst noch sauber aufsetzen willst, passt dazu auch der Beitrag Login via SSH Key.

Welche Post-Quanten-Technik heute wirklich aktiv ist

In OpenSSH auf Debian 13 ist der aktuell interessante Teil vor allem der KEX-Mechanismus, also der Key Exchange.

Das kannst du dir so merken:

Benutzer-Key: meist ED25519 oder FIDO-Key
Host-Key: meist ED25519 oder RSA/ECDSA
Verbindungsaufbau: hybrid mit ML-KEM und X25519 möglich

Von vollständig post-quantenfesten SSH-Keys für alle Bereiche zu sprechen, wäre deshalb zu pauschal. Korrekt ist eher:

Debian 13 bringt bereits einen modernen hybriden Post-Quanten-Schlüsselaustausch in OpenSSH mit, während Benutzer- und Host-Keys im Alltag weiterhin auf klassischen, bewährten Verfahren wie ED25519 basieren.

Prüfen, welche KEX-Algorithmen dein System kennt

Zuerst kannst du dir auf dem Client anzeigen lassen, welche Schlüsselaustauschverfahren OpenSSH überhaupt kennt:

1	ssh -Q kex

In der Ausgabe sollten unter Debian 13 unter anderem Einträge wie diese auftauchen:

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

Interessant sind hier vor allem die hybriden Einträge mit ML-KEM oder SNTRUP.

Wenn du die Ausgabe direkt filtern willst:

1	ssh -Q kex \| grep -E 'mlkem\|sntrup\|curve25519'

Prüfen, was dein SSH-Client bevorzugt

Nur weil ein Algorithmus verfügbar ist, heißt das noch nicht automatisch, dass er in deiner effektiven Konfiguration ganz oben steht. Das kannst du so prüfen:

1	ssh -G dein-server.example \| grep ^kexalgorithms

Steht in der Ausgabe mlkem768x25519-sha256 weit vorne oder an erster Stelle, ist das genau das Verhalten, das man unter Debian 13 sehen will.

Wichtig dabei: Diese Ausgabe zeigt nur die effektive Client-Konfiguration und deren Reihenfolge. Ob eine konkrete Verbindung den Algorithmus am Ende wirklich mit dem Server aushandelt, siehst du damit noch nicht.

Prüfen, was in einer echten Verbindung wirklich ausgehandelt wurde

Wenn du nicht nur die Präferenzliste sehen willst, sondern den tatsächlich verwendeten Schlüsselaustausch, hilft die Verbose-Ausgabe einer echten Verbindung:

1	ssh -vv -o BatchMode=yes dein-user@dein-server true 2>&1 \| grep 'kex: algorithm:'

Taucht dort mlkem768x25519-sha256 auf, dann wurde genau dieser KEX in dieser Verbindung wirklich verwendet.

Das ist aussagekräftiger als ssh -G, weil hier die tatsächliche Aushandlung zwischen Client und Server sichtbar wird.

Auf dem Server die effektive SSHD-Konfiguration prüfen

Wenn du auch den Server selbst kontrollierst, kannst du dort die effektive Konfiguration anzeigen lassen:

1	sudo sshd -T \| grep kexalgorithms

Damit siehst du, welche Verfahren dein SSH-Server aktiv anbietet. Gerade bei älteren Konfigurationsdateien lohnt sich das, weil historisch übernommene Einstellungen moderne Defaults ausbremsen können.

Wann man manuell eingreifen sollte

In vielen Fällen musst du unter Debian 13 gar nichts tun. Wenn Client und Server beide aktuell sind, nutzt OpenSSH den hybriden Mechanismus bereits automatisch.

Manuelles Eingreifen ist vor allem dann sinnvoll, wenn:

alte Konfigurationen eigene KexAlgorithms gesetzt haben
du gemischte Umgebungen mit alten Servern betreibst
du das Verhalten bewusst testen oder erzwingen willst
du nachvollziehen möchtest, ob ein bestimmter Server modern genug ist

Hybriden KEX testweise auf Client-Seite erzwingen

Wenn du prüfen willst, ob ein Zielserver den modernen Austausch sauber unterstützt, kannst du das testweise explizit vorgeben:

1	ssh -o KexAlgorithms=mlkem768x25519-sha256 dein-user@dein-server

Kommt die Verbindung zustande, unterstützen beide Seiten den gewünschten Austausch.

Scheitert die Verbindung mit einer Meldung zu fehlender KEX-Überschneidung, ist der Zielserver oder ein dazwischenliegendes System zu alt oder anders konfiguriert.

Dauerhaft in der Client-Konfiguration festlegen

Wenn du für einen bestimmten Host oder eine bestimmte Hostgruppe bewusst auf moderne Verfahren setzen willst, kannst du das in der SSH-Config hinterlegen:

1 2	Host mein-server KexAlgorithms ^mlkem768x25519-sha256,sntrup761x25519-sha512

Mit dem vorangestellten ^ setzt du diese Verfahren an den Anfang der bestehenden Default-Liste, statt alle anderen unterstützten KEX-Algorithmen komplett zu ersetzen.

Das ist für dieses Thema meist die bessere Wahl, weil es gezielt moderne Verfahren bevorzugt, ohne unnötig Kompatibilität abzuschneiden.

HostKeyAlgorithms oder PubkeyAcceptedAlgorithms solltest du nur dann zusätzlich einschränken, wenn du ganz bewusst auch Signaturalgorithmen für Host- oder Benutzer-Authentifizierung härten willst. Für das Post-Quanten-Thema beim SSH-Transport ist das nicht zwingend erforderlich.

Das ist allerdings nur dann sinnvoll, wenn du genau weißt, dass die Gegenseite diese Verfahren unterstützt.

Zu restriktive Vorgaben können sonst schnell zu Verbindungsproblemen führen, vor allem bei Fremdservern, alten Appliances oder Hosting-Umgebungen mit konservativer SSH-Konfiguration.

Serverseitig den Fokus auf moderne Verfahren legen

Wenn du den eigenen SSH-Server härtest, kannst du in der sshd_config ebenfalls gezielt moderne KEX-Verfahren priorisieren. Ein mögliches Beispiel wäre:

1	KexAlgorithms ^mlkem768x25519-sha256,sntrup761x25519-sha512

Auch hier sorgt ^ dafür, dass die bestehenden Default-Verfahren erhalten bleiben und nur die Priorität angepasst wird.

Host-Keys solltest du separat und bewusst umbauen. Das ist ein eigenes Härtungsthema und nicht notwendig, um den hybriden Post-Quanten-KEX zu nutzen.

Danach die Konfiguration prüfen:

1	sudo sshd -t

Und anschliessend den Dienst neu laden oder neu starten:

1	sudo systemctl restart ssh

Wichtig: Solche Anpassungen sollte man nie blind auf einem entfernten Server ohne offene zweite Sitzung vornehmen. Eine fehlerhafte SSH-Konfiguration sperrt einen sonst im schlechtesten Fall selbst aus.

Was heute noch nicht der Normalfall ist

Hier liegt die eigentliche Einordnung des Themas.

Unter Debian 13 bekommst du mit OpenSSH schon einen modernen hybriden Post-Quanten-Schlüsselaustausch. Was du im Standardbetrieb aber noch nicht bekommst, sind breit etablierte, alltagstaugliche Post-Quanten-Signaturschlüssel für Benutzer-Authentifizierung und Host-Keys im gleichen Reifegrad wie ED25519.

Deshalb ist die realistische Empfehlung aktuell:

Benutzer-Keys weiter als ED25519 erzeugen
Host-Keys möglichst modern halten, ebenfalls gerne ED25519
den hybriden KEX von OpenSSH 10 nutzen statt ihn versehentlich wegzukonfigurieren

Das ist derzeit die vernünftigste Kombination aus Praxistauglichkeit, Kompatibilität und Zukunftssicherheit.

FIDO-Keys als sinnvolle Ergänzung

Wer den Schutz seines SSH-Logins weiter verbessern will, sollte neben dem Post-Quanten-Thema noch einen zweiten Punkt im Blick behalten: hardwaregestützte Schlüssel.

OpenSSH unterstützt auch FIDO-basierte Schlüsseltypen wie:

ed25519-sk
ecdsa-sk

Diese sind nicht automatisch post-quantenfest, verbessern aber den praktischen Schutz des privaten Schlüssels deutlich, weil die Signatur an ein physisches Gerät gebunden ist. Für viele Admins ist das im Alltag ein ebenso großer Sicherheitsgewinn wie die Modernisierung des KEX.

Typische Stolperfallen in bestehenden Setups

In der Praxis sind es oft nicht fehlende Pakete, sondern alte Konfigurationen, die moderne Kryptografie verhindern. Typische Beispiele sind:

übernommene KexAlgorithms-Zeilen aus alten Howtos
alte HostKeyAlgorithms-Vorgaben
Legacy-Kompatibilität für einzelne Altgeräte
Konfigurationsschnipsel in /etc/ssh/ssh_config.d oder /etc/ssh/sshd_config.d

Wenn du moderne Defaults nutzen willst, lohnt sich deshalb immer ein Blick auf:

/etc/ssh/ssh_config
/etc/ssh/ssh_config.d/
/etc/ssh/sshd_config
/etc/ssh/sshd_config.d/

Je älter ein Server historisch gewachsen ist, desto größer ist die Chance, dass dort Sicherheit nicht durch fehlende Software, sondern durch alte Ausnahmen ausgebremst wird.

Fazit

Debian 13 ist beim Thema SSH und Post-Quanten-Kryptografie erfreulich gut aufgestellt. Mit OpenSSH 10.0p1 ist hybrider Post-Quanten-Schlüsselaustausch bereits im Alltag angekommen, konkret über mlkem768x25519-sha256.

Der wichtigste Punkt für die Praxis ist dabei die saubere Einordnung: Nicht dein kompletter SSH-Login besteht plötzlich aus Post-Quanten-Keys, sondern vor allem der Verbindungsaufbau wird moderner und widerstandsfähiger gegen künftige store now, decrypt later-Szenarien.

Die sinnvolle Empfehlung für Debian 13 lautet deshalb aktuell:

ED25519 weiter für Benutzer- und Host-Keys verwenden
hybride KEX-Verfahren nicht aus Versehen deaktivieren
alte SSH-Konfigurationen auf überholte Vorgaben prüfen

Genau das ist im Moment der technisch saubere Mittelweg: modern genug für neue Risiken, aber ohne unnötige Kompatibilitätsprobleme im Alltag.