Die Debatte um Quantenrechner klingt nach übermorgen. Ein Teil davon ist es nicht: Wer heute verschlüsselten Verkehr mitschneidet und aufhebt, kann ihn entschlüsseln, sobald die Technik reicht. Für Daten mit langer Schutzdauer ist das ein Problem der Gegenwart, für den SSH-Zugang zu einem Webserver eher nicht.
Es ist nichts akut kaputt, und die Maßnahme ist in den meisten Fällen ein Nebeneffekt eines Updates. Wichtig ist die Einordnung: Der Schlüsselaustausch ist betroffen, die Anmeldung mit Ed25519-Schlüsseln praktisch nicht, wer das verwechselt, tauscht die falsche Sache aus.
Zwei Dinge, die man auseinanderhalten muss#
Der Schlüsselaustausch legt fest, mit welchem Sitzungsschlüssel die Verbindung verschlüsselt wird. Ein aufgezeichneter Austausch lässt sich später brechen, deshalb ist das der Teil mit dem Zeitproblem („jetzt sammeln, später entschlüsseln“).
Die Signatur (dein Ed25519-Schlüssel) beweist, wer du bist. Sie wird im Moment der Anmeldung geprüft. Eine später gebrochene Signatur nützt niemandem rückwirkend, hier ist der Zeitdruck deutlich geringer.
Kurz: Beim Schlüsselaustausch handeln, bei den Schlüsseln gelassen bleiben.
Was OpenSSH tut#
OpenSSH kennt seit Version 9.0 einen hybriden Austausch ([email protected]) und seit Version 9.9 zusätzlich mlkem768x25519-sha256, der auf dem inzwischen standardisierten ML-KEM beruht. Ab OpenSSH 10 ist dieses Verfahren die Voreinstellung; neuere Versionen weisen zudem darauf hin, wenn eine Verbindung ohne quantensicheren Anteil zustande kommt.
Hybrid heißt: klassisches X25519 und das neue Verfahren zusammen. Bricht eines, trägt das andere. Das ist der Grund, warum die Umstellung risikoarm ist.
Prüfen, was tatsächlich ausgehandelt wird#
# Version auf beiden Seiten
ssh -V
ssh -Q kex | grep -Ei 'mlkem|sntrup'
# Was wurde bei dieser Verbindung wirklich verwendet?
ssh -v benutzer@host 2>&1 | grep -i 'kex: algorithm'
# erwünscht: mlkem768x25519-sha256 oder [email protected]Wenn dort etwas anderes steht, ist meist eine Seite zu alt, oder eine KexAlgorithms-Zeile aus einer alten Härtungsanleitung schneidet die neuen Verfahren weg.
# sshd_config: bevorzugen, ohne alte Clients auszusperren
KexAlgorithms mlkem768x25519-sha256,[email protected],curve25519-sha256,[email protected]
Kopierte Härtungslisten. Viele Anleitungen aus den Jahren davor setzen KexAlgorithms auf eine feste Auswahl, die die neuen Verfahren nicht enthält und friert damit den Stand des Tages ein, an dem sie geschrieben wurden. Wer eine solche Zeile in seiner Konfiguration hat, sollte sie überprüfen statt sie zu vererben.
Wo es wirklich drängt und wo nicht#
| Fall | Dringlichkeit |
|---|---|
| SSH-Verwaltungszugang, kurze Sitzungen | gering, Update genügt |
| VPN-Verkehr mit langlebigen Geheimnissen | mittel, hybride Verfahren prüfen |
| Übertragung von Daten mit jahrzehntelanger Schutzdauer | hoch, eigene Betrachtung nötig |
| TLS für die Webseite | Sache der Bibliothek; kommt mit den Updates |
Für die meisten Betreiber eines einzelnen Servers heißt das: aktuelle Distribution fahren (Distribution aktualisieren), Updates automatisch einspielen (automatische Sicherheitsupdates) und das Thema ist erledigt, ohne dass man etwas Besonderes tun muss.
Was man nicht tun sollte#
Bestehende Ed25519-Schlüssel „vorsorglich“ gegen etwas Neues tauschen, das noch keine breite Unterstützung hat. Auch: Verfahren erzwingen, die alte Clients aussperren, ohne den Bestand zu kennen, die Liste dafür liefert die Bestandsliste.
Geschrieben aus dem laufenden Betrieb: MRMedia betreibt eigene Hosts, Kundendienste und deren Härtung in der EU. Eine veraltete Anleitung ist hier ein Sicherheitsproblem, kein Schönheitsfehler. Korrekturen bitte über Discord.
