When you log in to a server today, the SSH client and server agree on a method to exchange keys before encryption starts.
Post-quantum SSH hosting today means the server runs OpenSSH 10.0 or newer and offers the ML‑KEM key exchange (FIPS 203) as the default, while still accepting sntrup761x25519 for clients that have not upgraded.
The situation today: what SSH keys look like in 2026
Most businesses still rely on SSH for remote administration of Linux‑based appliances, cloud instances, and edge devices.
The handshake begins with the client sending a list of supported key‑exchange algorithms.
The server replies with the first algorithm it also supports.
If the server runs OpenSSH 9.0, the list includes sntrup761x25519 as the top post‑quantum option.
If the server runs OpenSSH 10.0, the list puts ML‑KEM at the top.
Both versions keep the older elliptic‑curve Diffie‑Hellman (Curve25519) and RSA options enabled for backward compatibility.
What is actually deployed: OpenSSH versions and KEX
OpenSSH 9.0 was released in early 2023 and made sntrup761x25519 the default post‑quantum KEX.
OpenSSH 10.0 arrived in mid‑2024 and switched the default to ML‑KEM, which is the NIST‑standardized FIPS 203 algorithm.
As of August 2026, the latest stable release from the OpenSSH project is 10.2, but many hosting providers still ship 10.0 or 10.1.
You cannot force ML‑KEM on a server that only offers 9.0; the negotiation will fall back to sntrup761x25519.
Likewise, a client that has not been upgraded past OpenSSH 8.9 will not see any post‑quantum option and will use Curve25519.
Why harvest‑now‑decrypt‑later matters for your business
Attackers can record an encrypted SSH session today and store the ciphertext.
When a sufficiently large quantum computer becomes available, they can run Shor’s algorithm to break the exchanged key.
If the key was exchanged with Curve25519 or RSA, the recorded session becomes readable.
With a post‑quantum KEX such as ML‑KEM or sntrup761x25519, the same attack fails because the underlying problem is believed to resist quantum solutions.
If you lose one SSH key per month and each breach costs your operation $5,000 in downtime and remediation, that adds up to $60,000 a year.
That number is only an illustration; you can replace the figures with your own costs to see the exposure.
What to ask your hosting provider
Ask whether the SSH daemon is built from OpenSSH 10.0 or newer.
Ask which key‑exchange algorithms are enabled by default.
Confirm that ML‑KEM appears in the list offered by ssh -Q kex.
Ask if they allow you to disable legacy algorithms such as RSA‑SHA2‑256 if you want a stricter policy.
Request a recent version of the server’s /etc/ssh/sshd_config or the output of sshd -T to verify the active settings.
If the answer is that they only run OpenSSH 9.0, you know the highest post‑quantum option they can offer is sntrup761x25519.
How to verify the key exchange yourself
From any Linux or macOS terminal, run:
ssh -Q kex | grep -i mlkem
If the command returns a line containing mlkem768x25519sha2 or similar, the server will propose ML‑KEM.
To see what a specific host will actually choose, run:
ssh -G host.example.com | grep kexalgorithms
The output shows the ordered list the client will send; the first item that matches the server’s list is what gets used.
You can also test with a verbose connection:
ssh -vvv [email protected]
Look for the line debug1: kex: algorithm: ... to see which algorithm was agreed upon.
Acting on the information
If your current provider cannot offer ML‑KEM, you have two practical paths.
First, ask them to upgrade the OpenSSH package to 10.0 or later; most Linux distributions now provide it in their standard repositories.
Second, consider moving workloads to a provider that already runs the newer version.
Either way, you reduce the risk of harvest‑now‑decrypt‑later attacks on your administrative traffic.
For help evaluating your SSH fleet and planning a migration, review our AI consulting for your operation.
You can also see what we build in the automation space at what we build.