Setting Up SSH with Post-Quantum Encryption

SSH is likely the most ubiquitous tool on our servers and, for this reason, the most exposed. It is also the server most likely exposed to the internet, especially since many organizations use cloud providers and rely on SSH as the sole method to connect to servers remotely.

With quantum computing getting closer by the day, its traditional key exchange methods are vulnerable to the long-term “harvest now, decrypt later” risk: an attacker can record encrypted traffic today and try to decrypt it later when large quantum computers become practical. The practical response in 2026 is not to replace SSH entirely, but to enable hybrid post-quantum key exchange in OpenSSH so sessions stay protected by both classical and post-quantum cryptography at the same time.

You may have seen already the warning recent OpenSSH started showing:

WARNING: connection is not using a post-quantum key exchange algorithm. This session may be vulnerable to “store now, decrypt later” attacks. The server may need to be upgraded. See https://openssh.com/pq.html

OpenSSH has already made this easier than many engineers realise. OpenSSH 9.9 added support for the hybrid key exchange algorithm mlkem768x25519-sha256, and OpenSSH 10.0 made it the default key agreement algorithm for ssh.

Why this matters

The key point is that post-quantum support in SSH today mainly affects key exchange, not your day-to-day CLI workflow. In practice, you still use SSH in the usual way, but the session establishment phase can negotiate a hybrid method that combines classical X25519 with ML-KEM, the NIST-standardized module-lattice key encapsulation mechanism standardized in FIPS 203.

That hybrid design matters because it reduces migration risk. The IETF draft for ML-KEM hybrid SSH states that the hybrid method is at least as secure as the strongest constituent key exchange, which is exactly why vendors are deploying hybrid schemes first instead of “pure PQ” modes.

What to deploy

For most Linux fleets, the practical baseline is simple:

• Upgrade clients and servers to OpenSSH 10.0 where possible, because mlkem768x25519-sha256 becomes the default for key agreement there.
• If 10.0 is not available, target OpenSSH 9.9 or newer, because that release introduced mlkem768x25519-sha256 support.
• Keep using modern host and user keys such as Ed25519 for authentication, because the OpenSSH post-quantum change is about session key agreement, not a wholesale replacement of every SSH primitive yet.

A useful distinction for engineers: OpenSSH’s current post-quantum rollout is about protecting the ephemeral secrets used to derive session keys. Your authorized_keys, host keys, agent workflow, and bastion patterns can largely stay the same while you upgrade the transport layer underneath them.

Practical setup

1. Check your SSH version

Start by checking the client and server versions:

1ssh -V
2sshd -V

You want OpenSSH 9.9+ for ML-KEM hybrid support, and ideally 10.0+ to get the hybrid method by default.

2. Inspect negotiated key exchange

From a client, check which key exchange algorithms are supported:

1ssh -Q kex

On a capable build, you should see mlkem768x25519-sha256. On OpenSSH 9.9, you may also see sntrup761x25519-sha512 as another hybrid post-quantum option.

3. Force hybrid KEX on the client

If you are on OpenSSH 9.9 and want to make the setting explicit, add this to ~/.ssh/config:

1Host *
2    KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256

This ordering prefers the ML-KEM hybrid method first, then falls back to the NTRU Prime hybrid method, then to classical Curve25519 only if needed for compatibility. OpenSSH 10.0 already prefers mlkem768x25519-sha256 by default, but being explicit can help during staged rollouts and audits.

For a one-off connection, you can also test it directly:

1ssh -o KexAlgorithms=mlkem768x25519-sha256 user@host

If the remote server supports the same method, the session should complete normally.

4. Set server policy

On the server, add or adjust this in /etc/ssh/sshd_config:

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

Then reload SSH:

1sudo systemctl reload sshd

This gives you a controlled migration path: new clients use hybrid PQ key exchange first, while older but still modern clients can fall back to Curve25519 if necessary. OpenSSH 10.0 also removes finite-field Diffie-Hellman methods from the default sshd key exchange list, reflecting a clear shift toward elliptic-curve and post-quantum-capable methods.

5. Verify what was negotiated

Use verbose mode when connecting:

1ssh -vv user@host

Look for a line showing the chosen KEX algorithm, ideally:

1kex: algorithm: mlkem768x25519-sha256

That is the simplest way to confirm the session actually used hybrid post-quantum key exchange instead of silently falling back. OpenSSH 10.0 specifically documents mlkem768x25519-sha256 as the new default for ssh.

Rollout plan

Start with bastions and jumphosts. These are the highest‑exposure admin entry points and a natural choke point to validate compatibility before touching the wider fleet. Upgrade the bastion client and sshd first, enforce or explicitly prefer hybrid KEX (e.g., mlkem768x25519-sha256), and monitor logs/telemetry for fallbacks.

As always, automation is the preferred approach. This is an important task and should not be performed manually. Use trusted automation platforms such as Ansible, Puppet, or Chef, and incorporate this into your baseline hardening process. We also recommend using Packer to build a standard base image that is thoroughly hardened to PCI DSS standards wherever possible.

Immutable servers: security and repeatability all in one | Digitalis Blog

Final thoughts

There are a few things engineers should not confuse:

• Post-quantum SSH in OpenSSH today does not mean your authentication keys are fully post-quantum; the current deployment focus is hybrid key exchange for transport security.
• “Supported” does not mean “used”; you must verify negotiated KEX during testing.
• Older appliances, embedded systems, Git endpoints, and alternative SSH implementations may lag behind OpenSSH support, so interoperability testing matters.

It is also worth noting that OpenSSH 10.0 describes mlkem768x25519-sha256 as standardised by NIST, safe against quantum attacks, and no less strong than curve25519-sha256, while also being faster than the previous default. That makes it unusual for a security upgrade: in many environments, it is both stronger and operationally easy to adopt.

The clock is ticking.

I for one welcome our new robot overlords

‍