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.htmlThat’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, 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 9.0, released in April 2022, made sntrup761x25519-sha512 (Streamlined NTRU Prime combined with classical X25519) the default. Version 9.9, released September 2024, added a second option: mlkem768x25519-sha256, a hybrid of NIST’s FIPS 203 ML-KEM standard with X25519. Version 10.0, released April 2025, made ML-KEM the new default scheme. Version 10.1, released October 2025, added the warning itself, via a new WarnWeakCrypto option in ssh_config that’s on by default.
So the warning isn’t new cryptography arriving. It’s a four-year-old capability 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. Both algorithms above have been supported by default since 2022 and 2024 respectively. If your client is on OpenSSH 10.1 or later and you still see the warning, the far end almost certainly doesn’t offer either post-quantum option, and negotiation fell back to a classical key exchange. WarnWeakCrypto no will 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.
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 says nothing about the server’s or your own host identity keys. Ed25519 and RSA host keys, the ones SSH uses to authenticate who you’re connecting to, remain exactly as quantum-vulnerable as they were before this warning existed, and no KexAlgorithms setting changes that.
That’s not a gap in OpenSSH’s implementation – it’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). SSH’s post-quantum key exchange addresses the first risk. It doesn’t touch the second.
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 just 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.
Almost nothing else in a typical estate does this. TLS libraries, VPN concentrators, internal service-to-service traffic, embedded and OT devices, message queues, database drivers – none of them print a warning when they fall back to something quantum-vulnerable. They just work, silently, on whatever the two ends happened to agree on. SSH getting a warning is the exception, not a preview of what’s coming everywhere else. For the rest 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.
Further reading: building an Enterprise CBOM, PQC migration planning, and our post on harvest now, decrypt later.