Post-Quantum SSH: What’s Already the Default and How to Carefully Harden OpenSSH

The “collect now, decrypt later” threat is real, but the assignment confuses it with something else and suggests that it is a new development. Post-quantum key exchange has been the default in OpenSSH since 2022, and ML-KEM since 2025. This guide explains the difference between key exchange and authentication keys, shows you how to verify what your server is currently using, and how to securely strengthen your key exchange.

What is unclear in the assignment

• Standard Approval: NIST standardized ML-KEM (FIPS 203) as early as 2024, not in the fall of 2026.
• Post-quantum defaults: OpenSSH 9.0 (April 2022) enabled the sntrup761x25519-sha512 hybrid key exchange as the default. Version 9.9 (September 2024) added mlkem768x25519-sha256, and version 10.0 (April 2025) made it the default.
• Warning: OpenSSH 10.1 (October 2025) began notifying clients when a connection does not use a post-quantum key exchange.
• RSA: I have found no evidence of a mass rejection of RSA keys by cloud platforms in 2026. Old ssh-rsa signatures using SHA-1 have been phased out since OpenSSH 8.8 (2021). RSA with sufficient key length is not currently “disabled” in SSH.
• Increase in attacks: I have not confirmed the claim of a massive increase in “Harvest Now, Decrypt Later” attacks. This threat is based on the assumption that today’s traffic logs will be crackable at some point in the future. Today, there is no quantum computer capable of breaking current cryptography.
• Ed25519-SK: It is neither “hybrid” nor post-quantum. It is a classic key tied to a hardware FIDO key.

Two different things: key exchange and authentication

With SSH, it is important to distinguish between two functions:

• Key exchange (KEX) establishes a secret key used to encrypt the entire session. If someone were to crack it from a log in the future, they could read all the traffic. Post-quantum hybrids are designed to counter this. This is the “harvest now, decrypt later” threat.
• Authentication (host and user keys and signatures) verifies the identity of each party. An attacker would have to break it at the time of connection, not retroactively. Therefore, a traffic log would be of no help in retrospect.

This means that key exchange is more urgent, and it is already protected in modern versions. Signature schemes are next on the agenda. OpenSSH 10.4 (July 2026) added an experimental composite signature that combines ML-DSA-44 with Ed25519, though it is still experimental.

How It Works: RSA and Grids

RSA is based on the difficulty of factoring large numbers into prime factors. Shor’s algorithm could do this quickly on a sufficiently large quantum computer. It also poses a threat to elliptic curves. Lattice cryptography, on which ML-KEM is based, relies on problems in multidimensional lattices for which no efficient quantum attack is known.

A hybrid approach combines the best of both worlds. The resulting key is calculated from both secrets, such as K = HASH(K_PQ || K_CL)one from ML-KEM-768 and the other from the classical X25519. If a vulnerability were found in the new algorithm, the classical part would still provide protection. If the classical part were compromised, the post-quantum part would provide protection. The project documentation states that the hybrid is “at least as strong as curve25519.”

Step 1: Find out what you're using

ssh -V                                   # verzia klienta
ssh -Q kex | grep -E 'mlkem|sntrup'      # čo klient podporuje

# čo sa skutočne dohodlo s konkrétnym serverom
ssh -vv user@server 2>&1 | grep -i 'kex: algorithm'

# na serveri: čo sshd ponúka
sudo sshd -T | grep -i kexalgorithms

Depending on the OpenSSH version on the server, you either have both hybrids (9.9 and newer) or just sntrup761x25519 (9.0 through 9.8). For example, Ubuntu 24.04 LTS ships with version 9.6, so it only supports sntrup761 and does not have ML-KEM. If the server is older than 9.0, post-quantum key exchange isn’t available, and you’ll need to update it. Updating is better than any configuration tweaking.

Step 2: Authentication Key

For user keys, Ed25519 is a reasonable choice today:

ssh-keygen -t ed25519 -a 100 -C "macbook-2026"

If you have a FIDO2 hardware key, you can generate a device-bound key:

ssh-keygen -t ed25519-sk -C "macbook-fido"

The built-in OpenSSH in macOS may not support hardware keys. In that case, use a newer version, such as one from Homebrew, and check which ssh-keygen one is being used. For RSA, if you need it for an older system, use at least 3072 bits.

Step 3: Secure the server (with caution)

The configuration is not written to the main file, but to a separate file. Modern distributions load the directory /etc/ssh/sshd_config.d/ and apply the first match, so the name with the lower number takes precedence:

# /etc/ssh/sshd_config.d/10-pq.conf  (OpenSSH 9.9 a novší)
KexAlgorithms mlkem768x25519-sha256,[email protected]
PasswordAuthentication no
PubkeyAuthentication yes

For OpenSSH 9.0 through 9.8, remove the "mlkem" entry and leave only "sntrup761":

KexAlgorithms [email protected]

Be careful about locking: this setting means that anyone unfamiliar with these algorithms—such as older clients, certain automation tools, or devices—will not be able to connect. Follow these steps:

1. Open a second SSH connection and keep it open throughout the entire process.
2. Check the configuration: sudo sshd -t.
3. Load it: sudo systemctl reload ssh (on RHEL and related distributions, the sshd service).
4. From the new terminal, test logging in, including from all the clients you use.
5. Ensure you have alternative access (provider console) in case of an error.

If you also need to enable classic exception handling, use the Match for specific users or addresses instead of compromising the entire server. If you just want to add a preferred algorithm without removing the others, use the prefix ^ (to add it to the top of the list).

What even this won't solve

• There is no such thing as a “cryptographically unbreakable” server. Hosting keys and signatures are still conventional. Implementation vulnerabilities, poor key management, and stolen keys are far more likely risks than a quantum attack.
• This only protects SSH. Other services, such as TLS, have their own transition schedules.
• If the client you’re connecting to doesn’t support post-quantum algorithms, the connection will fail or (if the restriction is disabled) fall back to a classical key exchange.

What to Take Away From This

The most important thing is not some aggressive configuration. It’s having the latest version of OpenSSH on both clients and servers. Then, post-quantum key exchange is used automatically. Strictly limiting the list of algorithms makes sense for servers that are only accessed by your modern clients, and requires careful testing. The next step is post-quantum signatures, but these are still experimental.