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.
| Serverversion | Post-Quantum-Unterstützung |
|---|---|
| Älter als 9.0 | Nicht standardmäßig |
| 9.0 und neuer | sntrup761x25519-sha512@openssh.com, standardmäßig aktiviert, seit 9.9 auch sntrup761x25519-sha512 genannt |
| 9.9 und neuer | Zusätzlich mlkem768x25519-sha256 |
| 10.0 und neuer | mlkem768x25519-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
- Post-Quantum Cryptography, OpenSSH
- OpenSSH Release Notes
- ssh_config(5), WarnWeakCrypto
- sshd_config(5), KexAlgorithms