OpenSSH and post-quantum cryptography: practical checklist for SysAdmins
How to prepare Linux servers, appliances, and homelabs for OpenSSH's post-quantum key exchange without breaking compatibility, automations, and emergency access.
OpenSSH is one of those foundations that you tend to leave alone as long as it works. It's understandable: if SSH breaks, it's not a secondary service that breaks, it's the way you get into your servers. However, 2025 marked an important milestone: OpenSSH started moving the default key exchange towards post-quantum hybrid algorithms, particularly combinations like mlkem768x25519-sha256, which merge a modern elliptic curve-based mechanism with ML-KEM, the standard derived from Kyber published by NIST as FIPS 203.
For a SysAdmin, it doesn't mean "changing all keys tomorrow morning." It means understanding where your infrastructure is already ready, where it is fragile, and which compatibilities might break during distribution upgrades. In a homelab or a small company, recent Debian versions, dated NAS devices, embedded firewalls, old appliances, Windows clients with PuTTY, or automation tools that no one has touched in a while often coexist. That is where the topic becomes practical.
What really changes
SSH key exchange is used to establish a session secret between client and server. User and host public keys remain a different piece of the puzzle: ed25519, ecdsa, or rsa continue to be used to authenticate identities and hosts. The post-quantum part comes into play mainly during the initial session negotiation.
The hybrid logic is cautious: it doesn't throw away X25519, which is solid and fast today, but combines it with ML-KEM. If one of the two components remains secure, the session retains significant protection. It is a sensible choice for the transition period, because the risk