Post-Quanten-Standardeinstellungen von OpenSSH und die Warnung vor nicht quantensicherem Schlüsselaustausch

Ziel

Stand: 25. Oktober 2026. Eine Warnung vor nicht quantensicherem Schlüsselaustausch durch Prüfung der tatsächlichen Gegenstellen und ihrer Einstellungen beheben. Vor einer Richtlinienänderung die Post-Quanten-Hinweise von OpenSSH, die Dokumentation der installierten Pakete und die wirksame Konfiguration erneut prüfen. Die folgenden Versionsmeilensteine beschreiben Funktionen des Ursprungsprojekts, nicht den neuesten Stand der Sicherheitsupdates.

Die OpenSSH-Hinweise nennen ein Post-Quanten-Verfahren als Standard seit 9.0, zunächst mit dem sntrup-Hybridverfahren. Die Unterstützung für mlkem768x25519-sha256 kam mit 9.9 hinzu; in 10.0 wurde es zum Standard. OpenSSH 10.1, veröffentlicht am 6. Oktober 2025, führte eine Warnung ein, wenn eine Verbindung einen nicht quantensicheren Schlüsselaustausch auswählt.

Voraussetzungen

Ein autorisiertes Testkonto, Zugriff auf die Konfiguration beider Gegenstellen und eine bestehende Administrationssitzung oder Konsole für die Wiederherstellung bereithalten. Die Warnung betrifft den Schutz vor einer künftigen Entschlüsselung aufgezeichneten Datenverkehrs. Sie belegt für sich genommen weder ein Abfangen der Verbindung noch eine Kompromittierung oder eine fehlgeschlagene Hostschlüsselprüfung.

Schritte

1. Die tatsächliche SSH-Implementierung an jedem Endpunkt ermitteln, einschliesslich Appliances und eingebetteter Git-Dienste. Auf dem Client ssh -V ausführen. Ein ähnlich benanntes Paket oder die Clientversion belegt nicht, was ein entfernter Dienst unterstützt.

2. Die lokal unterstützten Verfahren mit ssh -Q kex prüfen und anschliessend die Einstellungen untersuchen, die für das tatsächliche Ziel gelten:

   ssh -G server.example
   

   kexalgorithms und die zutreffenden hostspezifischen Einstellungen prüfen. Die Abfrage unterstützter Algorithmen zeigt nicht die tatsächlich erlaubte Liste; keine der beiden Angaben zeigt, welches Verfahren tatsächlich ausgehandelt wurde.

3. Auf einem OpenSSH-Server mit ausreichenden Berechtigungen sshd -T verwenden, um die wirksame Konfiguration zu prüfen. Seine Verbindungsparameter -C verwenden, wenn relevante bedingte Einstellungen ausgewertet werden müssen. Eingebundene Dateien und zentral verwaltete Beschränkungen vor Änderungen prüfen.

4. Unterstützte Anbieterupdates und die Entfernung veralteter Beschränkungen bevorzugen, die hybride Algorithmen unterdrücken. Ältere Gegenstellen können sntrup761x25519-sha512@openssh.com anbieten; die Versionshinweise zu 9.9 ergänzen ausdrücklich den Namen sntrup761x25519-sha512 ohne Zusatz. Dies ist genauer als die verkürzte Benennung in der Post-Quanten-Übersicht. Eine Gegenstelle mit dem älteren Hybridverfahren muss nicht allein deshalb als ausschliesslich klassisch eingestuft werden, weil ihr ML-KEM fehlt. Die exakten Namen bestätigen, die jeder Build akzeptiert.

5. Eine geänderte Serverkonfiguration vor dem üblichen Neuladen auf der jeweiligen Plattform mit sshd -t validieren. Die Sitzung zur Wiederherstellung offen halten. Eine separate Verbindung herstellen, ohne eine bestehende Multiplex-Sitzung wiederzuverwenden:

   ssh -vv -S none server.example
   

   Den ausgewählten Schlüsselaustauschalgorithmus in der Diagnoseausgabe ablesen und die normale Hostauthentifizierung sowie die Anmeldung prüfen. Die Testsitzung nach Abschluss schliessen. Keine ungeschwärzten Diagnoselogs mit Hostnamen oder Kontoinformationen veröffentlichen.

6. Wenn eine alte Gegenstelle noch nicht aktualisiert werden kann, die verantwortliche Stelle, die Vertraulichkeit der Daten und den Ersatzplan dokumentieren. Die Warnung sichtbar lassen, sofern keine geprüfte, eng begrenzte Ausnahme erforderlich ist. Das Unterdrücken der Warnung mit WarnWeakCrypto ändert die Meldungen; es verbessert nicht die Kryptografie.

Erwartetes Ergebnis

Eine neue Verbindung wählt einen zulässigen hybriden Schlüsselaustausch, oder eine ausdrücklich dokumentierte Ausnahme für Altsysteme bleibt bestehen. Bestehende Clients verbinden sich weiterhin wie vorgesehen, und die Hostschlüsselprüfung wird weiterhin erzwungen.

Grenzen und Prüfbasis

Dieses Verfahren beruht auf der Dokumentation des Ursprungsprojekts, nicht auf einer getesteten Systemlandschaft. Nachgelagerte Paketierung und Richtlinien können abweichen. Strenge Hostschlüsselprüfungen nicht deaktivieren, Authentifizierungskontrollen nicht entfernen und Nutzerschlüssel nicht allein zur Behebung einer Schlüsselaustauschwarnung ersetzen. Ein erfolgreicher hybrider Austausch ist ein Nachweis für die Schlüsselvereinbarung dieser Verbindung, keine Aussage darüber, dass sämtliche Authentifizierungsverfahren quantensicher sind.