OpenSSH 9.9, released in September 2024, closed a transition long promised: native support for hybrid post-quantum cryptography in the SSH key exchange. In August 2025 we have a year of track record, updated clients in most serious distributions, and enough companies starting to think about migration. This post gathers the concrete steps we took on the jacarsystems.net VPSes and the decisions avoided with a bit of planning.
Why now and not in five years
The reason to migrate SSH to post-quantum is not that a quantum computer could break your connection tomorrow. Not even in five years. The reason is the store-now, decrypt-later attack. An adversary capturing your SSH traffic today can archive it and, when a quantum computer capable of breaking Diffie-Hellman or ECDH appears, decrypt the whole session retroactively. If that session contained passwords, secrets, API keys, or sensitive data still valid in ten or fifteen years, today’s capture retains value.
This risk does not apply equally to everyone. For everyday SSH to a hobby server, the probability of being a target for selective storage is low and attack cost is high. For corporate, financial, healthcare infrastructure, or any use where long-horizon secrets circulate, the calculus shifts. NIST’s recommendation since 2024 is to migrate to post-quantum in any communication with long-term sensitive data, starting now.
What OpenSSH 9.9 and 10.0 bring
The key novelty of OpenSSH 9.9 is native support for ML-KEM-768, the post-quantum standard based on CRYSTALS Kyber selected by NIST. The implementation is hybrid: it combines ML-KEM with X25519 in the key exchange, so the session is safe if at least one of the two algorithms resists. If ECDH falls tomorrow because a quantum computer arrives, ML-KEM protects. If a flaw is found in ML-KEM, X25519 protects. This redundancy is the most important property of hybrid mode.
The concrete algorithm in OpenSSH has been called sntrup761x25519-sha512 since 2020, and 9.9 added mlkem768x25519-sha256 as the recommended option. Both are hybrid and post-quantum. The difference is that sntrup761 is based on NTRU Prime, which was not selected as a NIST standard, while ML-KEM 768 is the official standard. For new migrations, ML-KEM is the right choice.
OpenSSH 10.0, released in April 2025, made mlkem768x25519-sha256 the default key exchange when both ends support it. This means that if you update server and client to 10.0, hybrid mode activates without additional configuration. The log line KEX algorithm: mlkem768x25519-sha256 confirms the session is protected against a quantum adversary.
The easy part: host keys
Although the key exchange is already post-quantum in OpenSSH 9.9, the authentication keys, that is user and host keys, remain classical. This is deliberate: the post-quantum signature standard, ML-DSA based on Dilithium, has less time in stable specification and OpenSSH does not yet support it in the main branch. The project’s decision is to migrate the key exchange first, where store-now-decrypt-later risk is greater, and migrate signatures when the ecosystem matures.
This has an important practical implication: the Ed25519 host keys you already have remain valid and appropriate. You do not need to regenerate them. When ML-DSA reaches OpenSSH, likely in 2026, additional host keys will need to be added, not replace the existing ones. Migration is additive, not disruptive.
Concrete migration steps
The first step is updating OpenSSH to 9.9 or 10.0 on servers and clients. On Debian 13 Trixie, OpenSSH 9.9 is in default repositories. On Ubuntu 24.04 LTS it arrives via security update. On macOS, the bundled OpenSSH tends to lag; Homebrew offers a recent version. On Windows 11, the integrated OpenSSH reached 9.5 in the 24H2 update and 10.0 is available in 25H1.
The second step is adjusting server configuration to prioritise hybrid algorithms without dropping compatibility with older clients. In sshd_config we add a KexAlgorithms line with the preferred list at the front: mlkem768x25519-sha256 first, then sntrup761x25519-sha512 as fallback, then curve25519-sha256 for clients that do not yet support PQC. This lets modern clients use PQC automatically while older ones keep connecting over ECDH.
The third step is verifying that the hybrid session actually works. From a modern client, ssh -v server and look for the KEX algorithm line in client logs. It must show mlkem768x25519-sha256. If it shows curve25519-sha256, one of the two ends does not support PQC and the session is only classical. The difference is silent: the connection works the same, the user notices nothing, but post-quantum protection is not active.
What to break and what not to break
The main risk of a badly done migration is cutting off older clients. OpenSSH earlier than 8.5 supports neither sntrup761 nor ML-KEM. If sshd_config allows only PQC algorithms, those clients cannot connect. The recommended configuration always includes a classical fallback, at least curve25519-sha256, until all clients are verified to be updated.
Another trap is configuration management systems generating sshd_config from a config manager. Ansible, Puppet, and Chef may carry templates with KexAlgorithms inherited from three years ago that overwrite configuration without warning. I have seen several instances where OpenSSH was updated but the playbook kept imposing the old algorithm list, disabling PQC support without anyone noticing. Checking real state with ssh -Q kex on the server is the definitive verification.
A third point of attention is bastion and jump hosts. A session crossing two SSH hops is only post-quantum if each hop is. If the bastion runs OpenSSH 8.9 while the final server has 10.0, the first connection to the bastion is not protected against a quantum adversary and the user gets the false impression of being protected. Migration must cover the whole chain.
Performance impact
Hybrid PQC key exchange is more expensive than classical, but only in the initial handshake. Once the session is established, symmetric cryptography protecting data does not change. The handshake difference is between 5 and 15 additional ms on a modern machine, imperceptible for interactive sessions. For tools opening hundreds of SSH connections per second, such as mass backups or large-scale Ansible, aggregate cost can be visible and worth measuring.
Handshake size does grow noticeably. ML-KEM 768 includes 1184-byte public keys versus 32 bytes for X25519. A hybrid handshake sends about 2 KB more than a classical one. On high-latency networks or with small MTUs, this may require an extra packet. In practice it has never been a problem in my tests, but worth knowing if connecting from satellite or mobile networks with poor coverage.
Final verification
After migration, verification has three components. First, the kex list supported by the server via ssh -Q kex; it must include mlkem768x25519-sha256. Second, capture a real handshake with ssh -v and verify KEX algorithm shows the hybrid algorithm. Third, periodic sshd_config audit to detect accidental changes by other configuration processes.
A detail I liked implementing is an automated test in the CI pipeline that monthly checks servers expose the hybrid exchange. It is a five-line script that tries to connect forcing only mlkem768 and fails if the server does not accept it. That way any accidental change is caught early, not when someone audits manually six months later.
When it is worth it
My practical rule is that migrating SSH to hybrid is reasonable for any server with valuable long-term information. Production servers, corporate bastions, jump hosts to databases, repos with proprietary code, should migrate as soon as possible. The cost is a few minutes of configuration and a small risk of breaking old clients, mitigated by the fallback list. The gain is protection against a threat that grows each year.
For personal servers, homelab, and systems that never carry sensitive data, urgency is lower. But since the upgrade is cheap and the effect is only positive, there is no reason not to migrate too. The most common resistance I find is inertia, not rational calculation.
How to think the decision
Post-quantum cryptography is not an abstract topic for 2040, it is a concrete transition happening now. OpenSSH is probably the most critical service in infrastructure where the transition is easiest and least disruptive. If the team already has OpenSSH 9.9 or 10.0, adding one line to sshd_config is not work, it is hygiene. Leaving that line out is exactly the kind of silent technical debt that explodes five years later when there is no time to fix it.
What I find educational about this migration is that it introduces the concept of hybrid algorithm into operational routine. Over the coming years, other protocols will make similar transitions: TLS, IPsec, VPN. Details change, but the pattern is the same: adopt the new algorithm in hybrid mode, verify it works, remove the classical only when compatibility is secured. SSH is a good place to practice that pattern now that it is cheap, before having to apply it to the whole network stack at once.
The honest caveat is that pieces remain unresolved. Post-quantum signatures in SSH will not land before 2026. FIDO keys in hardware tokens do not support PQC in hardware. Audit tools do not yet detect well whether a session is hybrid. This does not invalidate migration today, but underlines that full transition is a multi-year process, not an event. Starting with key exchange is the logical step and the reward for doing it is disproportionately large relative to the effort.
