"WARNING: connection is not using a post-quantum key exchange algorithm": was bedeutet das?

Ihr OpenSSH-Client ab Version 10.1 hat mit diesem Server einen klassischen Schlüsselaustausch ausgehandelt, weil der Server oder eine Einstellung nichts Post-Quantum anbietet. Die Verbindung funktioniert und ist verschlüsselt. Das Risiko ist, dass aufgezeichneter Datenverkehr in Jahren von einem Quantencomputer entschlüsselt werden könnte. Die eigentliche Lösung ist OpenSSH 9.0 oder neuer auf dem Server, idealerweise 9.9 oder neuer. Nehmen Sie das Risiko für einen Host in Kauf, schalten Sie die Meldung dort mit WarnWeakCrypto no-pq-kex ab.

Sie möchten sehen, welche Server noch einen klassischen Schlüsselaustausch nutzen, ohne ssh -v zu lesen? Wardterm zeigt es für jede SSH-Sitzung. Zeigen

Aktualisiert am . Nachgestellt mit OpenSSH 10.3 auf macOS gegen einen echten OpenSSH-6.6-Server auf Ubuntu 14.04 und gegen OpenSSH 10.0 auf Debian 13, beschränkt auf klassische Algorithmen. Die Warnung und WarnWeakCrypto wurden mit OpenSSH 10.6 auf Alpine erneut geprüft.

Die vollständige Meldung

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded. See https://openssh.com/pq.html

Sie erscheint vor der Anmeldeabfrage, auf stderr. Die Verbindung läuft weiter, und der Exit-Status ändert sich nicht. Sie gibt es seit OpenSSH 10.1, Sie sehen sie also womöglich zum ersten Mal nach einem Update Ihres Clients, bei einem Server, der sich gar nicht geändert hat.

Was sie bedeutet

Der Schlüsselaustausch erzeugt das Geheimnis, das die Sitzung verschlüsselt. Die klassischen Algorithmen wie curve25519-sha256 sind gegen heutige Computer sicher. Ein ausreichend großer Quantencomputer könnte sie brechen, und jemand kann verschlüsselten Datenverkehr jetzt aufzeichnen und später versuchen. Das ist das „store now, decrypt later“ in der Meldung.

Die Warnung bedeutet nicht, dass Sie jemand angreift, dass Ihre Anmeldung heute einem Quantenangriff ausgesetzt ist oder dass Ihre Schlüssel ersetzt werden müssen. Es geht darum, wie lange der Inhalt Ihrer Sitzungen geheim bleiben muss. In einer Sitzung eingegebene Passwörter oder darüber kopierte Datenbank-Dumps sind das, worüber man nachdenken sollte.

Prüfen, was ausgehandelt wurde

ssh -v user@server true 2>&1 | grep -E 'remote software version|kex: algorithm'

Gegen einen Server, der die Warnung auslöst:

debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.13
debug1: kex: algorithm: curve25519-sha256@libssh.org

Und ein gutes Ergebnis, ohne Warnung:

debug1: kex: algorithm: mlkem768x25519-sha256

Die Post-Quantum-Namen enthalten mlkem oder sntrup. Um zu sehen, was Ihr eigener Client unterstützt:

ssh -Q kex | grep -E 'mlkem|sntrup'

Lösung 1: Der Server ist zu alt

Aktualisieren Sie OpenSSH auf dem Server, was meist bedeutet, die Distribution zu aktualisieren.

ServerversionPost-Quantum-Unterstützung
Älter als 9.0Nicht standardmäßig
9.0 und neuersntrup761x25519-sha512@openssh.com, standardmäßig aktiviert, seit 9.9 auch sntrup761x25519-sha512 genannt
9.9 und neuerZusätzlich mlkem768x25519-sha256
10.0 und neuermlkem768x25519-sha256 standardmäßig bevorzugt

Netzwerkgeräte und Appliances mit eigener SSH-Implementierung brauchen ein Firmware-Update des Herstellers. Bis dahin, oder bei einem Server, den Sie nicht ändern können, siehe Lösung 3.

Lösung 2: Eine Einstellung entfernt die Algorithmen

Ein aktueller Server kann die Warnung trotzdem auslösen, wenn eine Härtungsanleitung KexAlgorithms von Hand aus der Zeit vor diesen Algorithmen aufgelistet hat. Auf dem Server:

sudo sshd -T | grep -i '^kexalgorithms'

Steht mlkem768x25519-sha256 nicht in der Liste, suchen Sie die Zeile KexAlgorithms in /etc/ssh/sshd_config oder /etc/ssh/sshd_config.d/ und entfernen Sie sie, um zu den Standardwerten zurückzukehren, oder fügen Sie den Algorithmus hinzu. Prüfen und laden Sie dann neu. Auf Red-Hat-artigen Systemen heißt der Dienst sshd:

sudo sshd -t && sudo systemctl reload ssh

Auch Ihr Client kann das verursachen. Prüfen Sie es:

ssh -G server | grep -i '^kexalgorithms'

Suchen Sie in ~/.ssh/config nach einer Zeile KexAlgorithms, wenn diese Liste keine Post-Quantum-Namen enthält.

Um die übrigen Einstellungen zu prüfen, die eine solche Anleitung geändert hat, siehe sshd_config härten.

Lösung 3: Für einen Host abschalten

Ist ein Update nicht möglich und haben Sie das Risiko für diesen Host akzeptiert, tragen Sie dies in ~/.ssh/config ein:

Match host legacy.example.com
  WarnWeakCrypto no-pq-kex

Beschränken Sie es auf diesen Host, damit die Warnung anderswo nützlich bleibt. Für einen einzelnen Befehl nehmen Sie ssh -o WarnWeakCrypto=no-pq-kex user@server. Der Schalter -q blendet sie ebenfalls aus, aber auch andere Meldungen.

Skripte, die stderr lesen oder jede Ausgabe darauf als Fehler werten, können nach einem Client-Update anfangen zu scheitern. Beheben Sie den Server oder setzen Sie die Option für diesen Host in der Konfiguration des Skripts.

Fragen

Ist die Post-Quantum-Warnung gefährlich?

Keine unmittelbare Gefahr. Die Verbindung ist mit einem klassischen Verfahren verschlüsselt. Das Risiko ist, dass heute aufgezeichneter Verkehr später mit einem Quantencomputer entschlüsselt wird.

Mit welcher OpenSSH-Version verschwindet die Warnung?

Ein Server mit OpenSSH 9.0 oder neuer bietet sntrup761x25519, ab 9.9 auch mlkem768x25519-sha256. Eines davon genügt.

Wie schalte ich die Warnung für einen einzelnen Server ab?

Tragen Sie WarnWeakCrypto no-pq-kex in einem Match-host- oder Host-Block für diesen Server in ~/.ssh/config ein.

Quellen

Mehr zu Fehlermeldungen

Alle Anleitungen