"WARNING: connection is not using a post-quantum key exchange algorithm": what it means

Your OpenSSH client, version 10.1 or later, negotiated a classic key exchange with this server, because the server, or a setting, offers nothing post-quantum. The connection works and is encrypted. The risk is that recorded traffic could be decrypted years from now by a quantum computer. The real fix is OpenSSH 9.0 or later on the server, ideally 9.9 or later. If you accept the risk for one host, silence it there with WarnWeakCrypto no-pq-kex.

Updated . Reproduced with OpenSSH 10.3 on macOS against a real OpenSSH 6.6 server on Ubuntu 14.04, and against OpenSSH 10.0 on Debian 13 restricted to classic algorithms. The warning and WarnWeakCrypto were checked again with OpenSSH 10.6 on Alpine.

The full message

** 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

It appears before the login prompt, on stderr. The connection goes on, and the exit status does not change. It started with OpenSSH 10.1, so you may first see it after your client was updated, on a server that has not changed at all.

What it means

The key exchange creates the secret that encrypts the session. The classic algorithms, such as curve25519-sha256, are secure against today's computers. A large enough quantum computer could break them, and someone can record encrypted traffic now and try later. That is the "store now, decrypt later" in the message.

The warning does not mean that someone is attacking you, that your login is exposed to a quantum attack today, or that your keys need replacing. What is at stake is how long the content of your sessions must stay secret. Passwords typed in a session or database dumps copied through it are the kind of thing to think about.

Check what was negotiated

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

Against a server that triggers the warning:

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

And a good result, with no warning:

debug1: kex: algorithm: mlkem768x25519-sha256

The post-quantum names contain mlkem or sntrup. To see what your own client supports:

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

Fix 1: the server is too old

Upgrade OpenSSH on the server, which usually means upgrading the distribution.

Server versionPost-quantum support
Older than 9.0Not by default
9.0 and latersntrup761x25519-sha512@openssh.com, enabled by default, also named sntrup761x25519-sha512 since 9.9
9.9 and laterAlso mlkem768x25519-sha256
10.0 and latermlkem768x25519-sha256 preferred by default

Network devices and appliances with their own SSH implementation need a firmware update from the vendor. Until then, or on a server you cannot change, see fix 3.

Fix 2: a setting removes the algorithms

A recent server can still trigger the warning if a hardening guide listed KexAlgorithms by hand from before these algorithms existed. On the server:

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

If mlkem768x25519-sha256 is not in the list, find the KexAlgorithms line in /etc/ssh/sshd_config or /etc/ssh/sshd_config.d/, and remove it to go back to the defaults or add the algorithm. Then validate and reload. The service is sshd on Red Hat style systems:

sudo sshd -t && sudo systemctl reload ssh

Your client can cause this too. Check it:

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

Look for a KexAlgorithms line in ~/.ssh/config if that list has no post-quantum names.

To review the other settings such a guide may have changed, see how to harden sshd_config.

Fix 3: silence it for one host

When upgrading is not possible, and you have accepted the risk for that host, add this to ~/.ssh/config:

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

Keep it limited to that host, so the warning stays useful elsewhere. For one command, use ssh -o WarnWeakCrypto=no-pq-kex user@server. The -q flag hides it as well, but it hides other messages too.

Scripts that read stderr, or treat any output on it as a failure, may start to fail after a client update. Fix the server, or set the option for that host in the script's config.

Questions

Is the post-quantum warning dangerous?

There is no immediate danger. The connection is encrypted with a classic algorithm. The risk is that traffic recorded today could be decrypted later by a quantum computer.

Which OpenSSH version removes the warning?

A server with OpenSSH 9.0 or later offers sntrup761x25519, and from 9.9 also mlkem768x25519-sha256. Either one is enough.

How do I turn off the warning for one server?

Add WarnWeakCrypto no-pq-kex in a Match host or Host block for that server in ~/.ssh/config.

Sources

More in Error messages

All guides