OpenSSH 10.6 enabled a post-quantum signature algorithm and added a server option that logs connections without post-quantum key exchange. If those warnings are appearing in your logs, or you are wondering whether you need to do anything, this guide explains what is going on.

The threat: harvest now, decrypt later

Quantum computers large enough to break today’s public-key cryptography do not exist yet. But encrypted traffic can be recorded today and stored. If a sufficiently powerful quantum computer appears in ten or twenty years, an attacker could decrypt those recordings, including any passwords, keys, or data that crossed an SSH session.

That threat applies to key exchange, the step where both sides agree on a session key. It is why OpenSSH moved key exchange to post-quantum algorithms years ago.

Signatures, used to authenticate the server and your login key, are different: they only need to be unforgeable at the moment you connect. A future quantum computer cannot go back and impersonate you in a session that already happened. Post-quantum signatures matter, but less urgently.

The algorithms

Name	Type	Standard	In OpenSSH
ML-KEM (Kyber)	Key exchange	NIST FIPS 203	mlkem768x25519-sha256, default since 10.0
sntrup761	Key exchange	Not NIST	sntrup761x25519-sha512, default from 9.0 to 9.9
ML-DSA (Dilithium)	Signature	NIST FIPS 204	ssh-mldsa44-ed25519, enabled in 10.6

All of these are hybrids: each combines a post-quantum algorithm with a classical one (X25519 or Ed25519). Breaking the connection requires breaking both, so you lose nothing if a new algorithm turns out to have a flaw.

Check what your connections use

ssh -v user@server 2>&1 | grep 'kex: algorithm'

Output	Meaning
mlkem768x25519-sha256	Post-quantum, current standard
sntrup761x25519-sha512	Post-quantum, older default
curve25519-sha256, ecdh-sha2-*, diffie-hellman-*	Classical only

Check your versions too:

ssh -V                 # client
sshd -V 2>&1 | head -1 # server (or: dpkg -l openssh-server)

If either end is older than OpenSSH 9.0, or is a different SSH implementation, such as an old Dropbear on a router or a Java library on a network appliance, you will get classical key exchange.

On the server

Log clients that lack post-quantum key exchange. OpenSSH 10.6 adds WarnWeakCrypto to sshd_config, enabled by default. Watch the logs to find old clients:

journalctl -u ssh -u sshd --since today | grep -i 'post-quantum\|weak'

Prefer post-quantum key exchange explicitly. Modern OpenSSH already orders it first. If you have a hardened KexAlgorithms line copied from an old guide, it may be removing the post-quantum options. Check:

sudo sshd -T | grep -i kexalgorithms

A sensible modern setting is:

KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256

Keeping curve25519-sha256 last lets older clients connect while newer ones use post-quantum exchange. Drop it only when you know every client supports the others. Our SSH hardening guide covers the rest of the configuration.

Post-quantum keys

To try a hybrid ML-DSA key, both client and server need OpenSSH 10.6 or newer. First confirm your build supports it and see the exact key type name:

ssh -Q key | grep -i mldsa

Then generate a key with ssh-keygen -t and that type, in its own file so it does not replace your existing key, and check man ssh-keygen on your system for the accepted spelling.

Keys created with the earlier experimental @openssh.com variant must be regenerated. For now, Ed25519 keys remain the sensible default, and our ssh-keygen builder and SSH keys guide cover them. Expect post-quantum keys to become the recommendation once support is widespread.

What about everything else?

SSH is one piece. TLS in browsers and servers is moving to hybrid ML-KEM as well, and OpenSSL 3.5 and later support it. WireGuard does not yet have post-quantum key exchange in its standard protocol, though it supports a pre-shared key that adds a symmetric layer of protection; see our WireGuard guide.

A short checklist

1. Make sure servers and clients run OpenSSH 9.0 or newer, ideally 10.x
2. Check ssh -v output for mlkem or sntrup key exchange
3. Remove old KexAlgorithms overrides that exclude post-quantum options
4. Watch for weak-crypto warnings to find outdated clients and appliances
5. Keep Ed25519 keys for now, and test ML-DSA keys where both sides support them

Frequently Asked Questions

Is SSH vulnerable to quantum computers today?

No practical quantum computer can break SSH today. The concern is harvest now, decrypt later: an attacker recording encrypted traffic now could decrypt it once a large quantum computer exists. Post-quantum key exchange protects recorded sessions against that future threat.

Does OpenSSH already use post-quantum cryptography?

Yes. OpenSSH has used a hybrid post-quantum key exchange by default since 9.0, first sntrup761x25519 and, since OpenSSH 10.0, mlkem768x25519-sha256. If both ends run a modern OpenSSH, your sessions are already protected against harvest-now-decrypt-later.

What is a hybrid algorithm?

It combines a classical algorithm such as X25519 or Ed25519 with a post-quantum one such as ML-KEM or ML-DSA. An attacker has to break both, so the connection stays secure even if the newer post-quantum algorithm turns out to have a weakness.

Do I need new SSH keys?

Not urgently. Signatures only need to resist attack at the moment you log in, so a future quantum computer cannot retroactively misuse a recorded login. Ed25519 keys remain fine for now. Hybrid ML-DSA keys are worth testing, but both client and server need OpenSSH 10.6 or newer.

How do I see which key exchange a connection used?

Run ssh -v to the server and look for the line that says kex: algorithm, which names the key exchange. mlkem768x25519-sha256 or sntrup761x25519-sha512 means post-quantum; curve25519-sha256 or ecdh means classical only.

Why am I seeing warnings about weak crypto?

Recent OpenSSH versions warn when a connection uses key exchange that is not post-quantum safe. On the client this is WarnWeakCrypto in ssh_config; OpenSSH 10.6 adds a server-side option that logs such clients. The fix is to upgrade the older end of the connection.