“Connection Is Not Using a Post-Quantum Key Exchange Algorithm”: OpenSSH’s Warning Explained and Fixed

If you’ve SSH’d into an older server recently from an up-to-date machine, you may have seen this:

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

The short answer: the server you connected to did not offer either of the two post-quantum key exchange algorithms OpenSSH supports, mlkem768x25519-sha256 and sntrup761x25519-sha512, so the session fell back to a classical key exchange. The fix is on the server: upgrade it, or re-enable those algorithms if its configuration has removed them. The steps are below.

It’s not a bug and it’s not your terminal misbehaving. It’s OpenSSH, since version 10.1, telling you something true and specific: this particular connection just negotiated a key exchange algorithm that a future quantum computer could break. Here’s what’s actually behind the message, how to fix it, and what it does and doesn’t cover.

How we got here

OpenSSH has been shipping post-quantum key exchange for longer than most people realise. Version 8.5, released in March 2021, added [email protected] (Streamlined NTRU Prime combined with classical X25519), disabled by default. Version 8.9, released in February 2022, added it to the default list of key exchange algorithms, and version 9.0, released in April 2022, made it the default method. Version 9.9, released in September 2024, added a second option, mlkem768x25519-sha256, a hybrid of NIST’s FIPS 203 ML-KEM standard with X25519, and gave the NTRU Prime method the additional name sntrup761x25519-sha512. Version 10.0, released in April 2025, made ML-KEM the default. Version 10.1, released in October 2025, added the warning itself, controlled by a WarnWeakCrypto option in ssh_config that is on by default.

So the warning isn’t new cryptography arriving. It’s a capability that has been on by default since 2022 finally being surfaced to the person running the command, instead of negotiating silently in the background.

What actually triggers it

The warning fires client-side, and it usually means the server hasn’t caught up, not the client. According to OpenSSH, it means the server you connected to did not offer either post-quantum algorithm. Either the server runs an SSH implementation that doesn’t support them, or its KexAlgorithms setting has removed them. WarnWeakCrypto can silence the message, but that’s treating the messenger as the problem. The actual fix is upgrading the server, not the client’s tolerance for seeing the truth about it.

How to check and fix the warning

Work through it from the client to the server:

1. Check your client version with ssh -V. The warning was introduced in OpenSSH 10.1, so older clients will not show it even when the session is classical.
2. See what was negotiated. Connect with ssh -v user@host and look for the line starting debug1: kex: algorithm:. If it names mlkem768x25519-sha256 or sntrup761x25519-sha512 (with or without the @openssh.com suffix), the session used post-quantum key exchange. If it names something else, such as curve25519-sha256, it did not.
3. List what your client supports with ssh -Q kex.
4. Test whether the server offers a post-quantum method by forcing one: ssh -o KexAlgorithms=mlkem768x25519-sha256 user@host. If the server does not offer it, the connection fails with “no matching key exchange method found”. Repeat with [email protected], the name servers older than OpenSSH 9.9 use for the NTRU Prime method.
5. Check the server’s effective configuration with sudo sshd -T | grep -i kexalgorithms, which prints the configuration sshd will actually use. Check this rather than relying on the version number alone, because the KexAlgorithms setting decides what is offered.
6. Fix the server. OpenSSH 9.0 and later support sntrup761x25519-sha512, and 9.9 and later support mlkem768x25519-sha256. If the server already runs one of these versions, remove whatever is excluding them from KexAlgorithms in sshd_config. If the server is not OpenSSH, for example a network appliance, OpenSSH’s advice is to move to an SSH implementation that supports at least one of the two algorithms.
7. If you can’t fix the server yet, silence the warning only for that host and record the exception. OpenSSH recommends doing this selectively, for example with Match host unsafe.example.com followed by WarnWeakCrypto no-pq-kex in ssh_config. WarnWeakCrypto no turns off all of these warnings, which hides every other host that fails the same check.

From OpenSSH 10.6, released on 6 October 2026, the server can report the same thing. sshd_config gained its own WarnWeakCrypto option, enabled by default, which logs when a client uses a key agreement scheme that is not post-quantum safe. On upgraded servers, the logs become a list of the clients still connecting classically.

What it protects, and what it very deliberately doesn’t

This is the part worth being precise about, because the warning is easy to over-read. A post-quantum key exchange protects the confidentiality of the session – the data moving over that one connection, right now. It does nothing for the signature keys SSH uses to authenticate who you’re connecting to and who you are. Classical signature algorithms, including RSA and ECDSA, can be broken by a quantum computer according to OpenSSH’s own guidance, and no KexAlgorithms setting changes that.

That’s a different problem. A broken key exchange threatens confidentiality: something recorded today, decrypted once a quantum computer exists (harvest now, decrypt later, or HNDL). A broken signature algorithm threatens integrity instead: once RSA or ECC eventually falls, a forged signature could pass as legitimate under a key that was never actually used to sign it (trust now, forge later). OpenSSH notes there is no signature equivalent of “store now, decrypt later” for traffic already sent; the urgency is retiring classical signature keys before a capable quantum computer exists.

Post-quantum signatures are now arriving in OpenSSH too. Version 10.4, released in July 2026, added experimental support for a composite signature scheme combining ML-DSA-44 with Ed25519, not enabled by default. Version 10.6, released in October 2026, enabled the hybrid ssh-mldsa44-ed25519 signature algorithm. Keys generated with the earlier experimental support must be regenerated or removed.

Why an SSH session is worth this attention

Store-now-decrypt-later attacks are only worth the effort on data with a long enough shelf life to still matter once decryption becomes possible. SSH sessions are a good example of exactly that kind of traffic: source code, database credentials, infrastructure secrets, admin commands against production systems. None of that goes stale on a convenient schedule. A captured session from an unpatched server today is a bet that whatever crossed that connection is still worth reading in a decade.

The bigger point this warning is quietly making

What’s genuinely useful about OpenSSH 10.1 isn’t the specific algorithm swap. It’s that a piece of infrastructure started telling you, unprompted, whether one of your connections is protected against a known future risk. That’s discovery, at the protocol layer, for exactly one connection type.

Most of the rest of a typical estate gives no such signal. TLS libraries, VPN concentrators, internal service-to-service traffic, embedded and OT devices, message queues, database drivers – they generally just work, silently, on whatever the two ends happened to agree on. For that part of the estate, the equivalent information only exists if you go and build it: a live inventory of which systems use which cryptography, kept current as the estate changes.

That’s what a Cryptography Bill of Materials is for – agentless network discovery, source-code repository scanning, API integrations and PKI/HSM/key-management discovery, brought together into one place that answers the question OpenSSH now answers for a single SSH connection: is this actually protected, or not.

Upgrade the servers still failing that check. Then go find out how many other connections in your estate would fail it too, if anything were watching.

Frequently asked questions

What does ‘connection is not using a post-quantum key exchange algorithm’ mean?

It means the SSH server did not offer either of the post-quantum key exchange algorithms OpenSSH supports, mlkem768x25519-sha256 and sntrup761x25519-sha512, so the session used a classical key exchange. OpenSSH 10.1 and later show this warning by default, because a session protected only by classical key exchange could be recorded now and decrypted later by a quantum computer.

How do I fix the OpenSSH post-quantum warning?

Fix the server, not the client. Upgrade it to OpenSSH 9.0 or later, which supports sntrup761x25519-sha512, or 9.9 or later, which also supports mlkem768x25519-sha256. If it already runs one of those versions, check that the KexAlgorithms setting in sshd_config has not removed them. For a server that is not OpenSSH, move to an SSH implementation that supports at least one of the two algorithms.

How do I turn off the warning?

Set WarnWeakCrypto no-pq-kex in ssh_config. OpenSSH recommends doing this selectively, inside a Match host block for the specific servers whose risk you have accepted. WarnWeakCrypto no disables all of these warnings, which also hides other servers with the same problem.

Does post-quantum key exchange make SSH quantum-safe?

Not completely. It protects the confidentiality of the session against store now, decrypt later attacks. Authentication still relies on signature keys, and classical signature algorithms such as RSA and ECDSA can be broken by a quantum computer. OpenSSH 10.6 enabled the hybrid ssh-mldsa44-ed25519 signature algorithm to address that side.

Sources: OpenSSH, Post-Quantum Cryptography; OpenSSH, release notes for versions 8.5, 8.9, 9.0, 9.9, 10.0, 10.1, 10.4 and 10.6; OpenBSD manual pages ssh(1), ssh_config(5) and sshd(8); OpenSSH portable source, kex.c and ssherr.c; NIST, FIPS 203.

Further reading: building an Enterprise CBOM, PQC migration planning, and our post on harvest now, decrypt later.