PQC SSH Migration Guide: Hybrid Key Exchange and Host Key Plans

Every SSH session that still negotiates a classical key exchange can be recorded today and decrypted once a cryptographically relevant quantum computer exists. SSH carries administrator sessions, configuration pushes, backups, file transfers and automation credentials, so the traffic is worth harvesting. The good news is that the key exchange fix already ships in current OpenSSH and other clients; the harder parts are finding the servers, appliances and libraries that cannot negotiate it, and deciding what to do about host and user keys while post-quantum SSH signatures are still at Internet-Draft stage. This guide covers the hybrid key exchange methods and their status, inventory and telemetry, host key and user key plans, legacy appliance compatibility, rollout and measurement. It is for infrastructure, network and PAM engineers. Status statements were checked on 13 November 2026 and will move.

Key takeaways

• Key exchange is the urgent half. Recorded SSH traffic is exposed to "store now, decrypt later" attacks; OpenSSH notes that signatures carry no such retrospective risk, so they only need to be quantum safe before a quantum computer exists.
• Hybrid methods are now RFCs. sntrup761x25519-sha512 is RFC 9941 (April 2026) and the ML-KEM hybrids, including mlkem768x25519-sha256, are RFC 10042 (August 2026), both Informational.
• Configuration, not upgrades, is often the blocker. OpenSSH has defaulted to a hybrid since 9.0 and to mlkem768x25519-sha256 since 10.0, so a hard-coded KexAlgorithms line copied from an old hardening baseline is the usual reason a modern server negotiates classical only.
• Do not rush post-quantum host keys. OpenSSH 10.5 enabled the composite ssh-mldsa44-ed25519 signature, but its specification is a working group Internet-Draft that expires in February 2027; plan for it, pilot it, and keep Ed25519 as the trusted path for now.
• Legacy devices need an exception register, not silence. Appliances that cannot negotiate a hybrid get a named owner, a scoped WarnWeakCrypto exception, a network restriction and a retirement date.

What changes in SSH and what does not

SSH uses cryptography in three places, and post-quantum migration touches each differently. The SSH Key Management Guide covers the governance of keys and certificates; this page covers only the algorithm change. See the SSH Key Management Guide.

The hybrids pair a post-quantum key encapsulation mechanism with X25519 and hash both shared secrets together, so the session key stays safe unless both components fail. OpenSSH describes the combination as at least as strong as X25519 alone, which is why a hybrid is the right default while the young lattice algorithms accumulate analysis. For the general theory, see the Key Exchange and Diffie-Hellman Guide.

The hybrid key exchange methods and their status

The current sshd_config default for KexAlgorithms begins mlkem768x25519-sha256, then both sntrup761 names, then curve25519-sha256 and the NIST ECDH curves. The client default adds the finite field Diffie-Hellman groups at the end. Because both ends keep classical methods enabled, a peer that cannot do a hybrid simply falls back, which is what makes the change safe to deploy and also what makes silent fallback easy to miss.

• Which hybrid to prefer: mlkem768x25519-sha256 uses the NIST standard KEM (FIPS 203, final since 13 August 2024) is the OpenSSH default and the RHEL 10.1 default, and PuTTY has supported ML-KEM since 0.83. Keep sntrup761x25519-sha512 enabled as the second choice, because many deployed clients and servers from 2022 to 2024 support only that hybrid.
• FIPS-bound estates: RFC 10042 defines the NIST curve variants for environments where the classical half must be a validated ECDH curve. Confirm with your module vendor which hybrid combinations its validated boundary covers before you write a policy that requires one.
• Message size: RFC 9941 gives sntrup761x25519 public values of 1,190 bytes from the client and 1,071 from the server; ML-KEM-768 adds a 1,184 byte encapsulation key and a 1,088 byte ciphertext. That is trivial for servers but can matter on serial console servers, satellite links and small embedded stacks, so measure it there.

Find out what your estate negotiates

Inventory is the bulk of the work. A server running OpenSSH 10 with a stale crypto line is as exposed as a 2019 appliance, so check effective configuration and observed handshakes, not version numbers alone.

1. Server capability: on each host, sshd -T prints the effective KexAlgorithms after includes and Match blocks; ssh -Q kex lists what the local binary can do. Collect both with your configuration management tool alongside the OpenSSH version string.
2. Observed negotiation: a verbose client connection (ssh -v) shows the negotiated method in the "kex: algorithm:" debug line. Script this from a scanner host with a current client against every SSH listener, including network devices and appliances, and record the result per endpoint.
3. Server-side telemetry: from OpenSSH 10.5 the server WarnWeakCrypto option is on by default and logs when a client uses a key agreement that is not post-quantum safe. Forward those events to the SIEM: they identify old clients, automation libraries and partner systems you would never find from the server inventory.
4. Client-side warnings: from OpenSSH 10.1 the client warns users when a connection negotiates a non-post-quantum key agreement. Expect helpdesk tickets when 10.1 or later reaches laptops, and use them as a discovery feed.
5. Libraries and embedded stacks: SFTP and Git automation, Java and Python SSH libraries, managed file transfer products and device firmware each carry their own SSH implementation. List them in the cryptographic inventory with the version and the methods they offer. See the Cryptographic Inventory and CBOM Guide.

On RHEL, Red Hat states that hybrid ML-KEM with X25519 is the default and preferred SSH key exchange from RHEL 10.1, and that RHEL 9.7 and later can opt in with the DEFAULT:PQ system-wide policy. On those systems change the crypto policy, not sshd_config, or the next policy update will overwrite your edits.

Host key plan while PQ signatures settle

Host keys protect clients from talking to an impostor. A quantum attacker could only exploit a classical host key by forging signatures live, after a quantum computer exists, so there is time, but host keys and SSH certificate authority keys are long lived and baked into thousands of known_hosts files, which makes their replacement slow. Plan now, change later.

• Use the graceful rotation mechanism: OpenSSH's UpdateHostKeys lets a server announce additional host keys after authentication through the [email protected] extension, so clients learn a new key before the old one is removed. It applies to plain host keys, not certificates, and is on by default unless UserKnownHostsFile is overridden or VerifyHostKeyDNS is enabled.
• Prefer certificates for scale: with host certificates, clients trust an @cert-authority line rather than individual keys, so a future algorithm change is a re-issue. OpenSSH 10.6p2 added ssh-mldsa44-ed25519 as an allowed CA signature algorithm. See the SSH Protocol and Certificate Authority Guide.
• Do not pin algorithm lists: the current HostKeyAlgorithms default already lists ssh-mldsa44-ed25519 and its certificate type. A fixed list in a baseline will quietly block the transition later.

User keys, certificates and automation identities

User authentication keys are non-human identities in most estates: deployment pipelines, backup jobs, configuration management and AI agents all hold them. Their algorithm migration should ride on the lifecycle controls you need anyway.

• Short-lived certificates make the switch cheap: if automation receives user certificates valid for hours, changing the signing algorithm is a CA change; if it holds static keys in authorized_keys, it is a fleet-wide key replacement. TrustedUserCAKeys can list more than one CA key, which allows a classical CA and a composite CA to run side by side during the transition.
• Prioritise the CA keys: a forged CA signature yields access to every host that trusts it, so CA keys are first in line for composite signatures once the specification is stable and your HSM or signing service supports it. Keep them in hardware and record their algorithm in the inventory.
• FIDO-backed administrator keys: sk-ssh-ed25519 keys remain the strongest practical option for people today; they are classical, so track your authenticator vendor's post-quantum roadmap rather than abandoning them. See the Security Keys for SSH.
• Static keys that never rotate: these are the long tail. Each one you remove now is one you never have to migrate. See the Post-Quantum Migration for NHIs Guide.

Legacy appliances and compatibility

Switches, firewalls, storage arrays, out-of-band controllers, serial console servers and industrial gateways often run SSH stacks years behind current releases, and their vendors set the pace. Treat them as a managed exception class.

• Scope suppression tightly: OpenSSH documents WarnWeakCrypto no-pq-kex inside a Match host block to silence the warning for one named device. Never set it globally, or you lose the signal for every new regression.
• Jump hosts and gateways: with ProxyJump the client negotiates directly with the target through the tunnel, so the target must support a hybrid. A PAM gateway that terminates and re-originates SSH runs two separate negotiations, and post-quantum protection on one leg says nothing about the other. Check both. See the Securing the jump host and bastion itself.
• Ask suppliers in writing: include SSH key exchange and signature plans in procurement and renewal questions. See the PQC Supplier Readiness Questionnaire Template.

Rollout plan

1. Baseline (weeks 1 to 4): collect sshd -T output, versions and observed negotiation for every listener; classify each as hybrid ML-KEM, hybrid sntrup761 or classical.
2. Fix configuration first: remove or prepend outdated KexAlgorithms lines in baselines, golden images, CIS-derived templates and crypto policies. This is usually the largest single gain and needs no new software.
3. Upgrade clients and bastions: move administrator workstations, jump hosts, CI runners and automation libraries to versions that offer mlkem768x25519-sha256, so every capable server is reached with a hybrid.
4. Pilot ring: pick one server group and its clients, confirm negotiation in logs, watch for key exchange failures and latency for a week, then widen by ring.
5. Turn on telemetry: keep server and client WarnWeakCrypto at their defaults and alert on new classical negotiations from previously hybrid endpoints.
6. Exception register: every classical endpoint gets an owner, a network restriction, a vendor statement and a retirement date tied to your PQC programme milestones. See the Post-Quantum Cryptography Deadlines Tracker.
7. Signature pilot: in a lab, generate ssh-mldsa44-ed25519 host and user keys with a 10.5 or later build, test certificate issuance, HSM support and every client in the estate, and record what breaks. Do not make it the only trusted path until the draft is stable.
8. Rollback: because classical methods stay enabled, rolling back key exchange is one configuration value. Keep the previous known_hosts and CA trust lines until every client has learned the new ones; removing a trust anchor is the step you cannot undo quickly.

Decision guidance

• Small organisations: upgrading to current OpenSSH on servers and laptops and deleting old crypto lines delivers almost all the value. Host and user key changes can wait for the signature specification to reach RFC.
• Large or regulated estates: need the telemetry, exception register and supplier statements, plus a CA key plan with hardware support. The UK NCSC expects discovery and a plan by 2028, highest priority migrations by 2031 and completion by 2035.
• Hybrid or pure post-quantum: SSH has no pure ML-KEM method in RFC 10042; every defined method is a hybrid. That suits general use; organisations with national security obligations should take their algorithm list from their national authority. See the Post-Quantum Cryptography Migration Guide.

Detection and measurement

Attackers who want classical sessions do not need to break anything: a configuration change that drops the hybrids is enough. ATT&CK T1689 Downgrade Attack describes the behaviour, and T1040 Network Sniffing and T1557 Adversary-in-the-Middle describe the collection that makes harvested SSH valuable. SSH itself (T1021.004) is a common lateral movement path, which is why its session confidentiality matters.

Common failure patterns

• Copied cipher lines: a hardening template from before 2022 pins KexAlgorithms to curve25519-sha256 and the NIST curves, so new OpenSSH builds negotiate classical only. Remove values from the default with the - prefix instead of listing what you want.
• Global warning suppression: setting WarnWeakCrypto no or no-pq-kex everywhere to stop user complaints, which hides the next regression.
• Counting versions, not sessions: reporting the fleet as migrated because OpenSSH 10 is installed, while load balancers, gateways and automation clients still negotiate classical.
• Treating experimental keys as permanent: keys generated with the OpenSSH 10.4 experiment had to be regenerated in 10.5; a draft algorithm can change again before an RFC.
• Forgetting the far leg: confirming hybrid negotiation to a PAM gateway but not from the gateway to the target.

Framework mapping

Practitioner checklist

• Collect sshd -T output, versions and observed key exchange for every SSH listener, including appliances.
• Remove pinned KexAlgorithms lines from baselines, images and templates; on RHEL use the crypto policy.
• Prefer mlkem768x25519-sha256 and keep sntrup761x25519-sha512 as the second choice.
• Upgrade clients, jump hosts, CI runners and SSH libraries before chasing individual servers.
• Forward server WarnWeakCrypto events to the SIEM and alert on new classical sessions.
• Run an exception register for devices without hybrid support, with scoped Match host suppression only.
• Keep Ed25519 host keys as the trusted path; pilot ssh-mldsa44-ed25519 in a lab only.
• Move automation to short-lived certificates so a future signature change is a CA change.
• Put SSH post-quantum questions into supplier renewals and new purchases.

Standards and references

• IETF: RFC 10042, Post-Quantum/Traditional Hybrid Key Exchange with ML-KEM for Use in SSH
• IETF: RFC 9941, SSH Key Exchange Method Using Hybrid Streamlined NTRU Prime sntrup761 and X25519
• IETF: draft-ietf-sshm-composite-sigs, Post-Quantum Composite Signatures in SSH
• NIST: FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard
• NIST: FIPS 204, Module-Lattice-Based Digital Signature Standard
• OpenSSH: Post-Quantum Cryptography
• OpenSSH: Release Notes
• NCSC: Timelines for migration to post-quantum cryptography

Related NHI Mgmt Group resources: Post-Quantum Cryptography Migration Guide · SSH Key Management Guide · OpenSSH Server Hardening Guide · Hybrid Post-Quantum TLS Key Exchange Guide · NIST IR 8547 PQC Transition Timeline Guide