Store Now, Decrypt Later: How OpenSSH Protects Your Sessions from Future Quantum Computers

Introduction: a new warning in your terminal

You connect to an old server, and OpenSSH shows this text before the login prompt:

** 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

The connection still works. Your commands run as usual. So why does the client complain?

OpenSSH 10.1 added this warning in October 2025. The client shows it when the two sides agree on a key exchange that a future quantum computer can break. Nobody has such a computer today. But the warning is not about today. It is about traffic that an attacker records today and keeps for later.

In this article, I explain the attack behind the warning and how OpenSSH stops it. Then I show the commands and the configuration that you need to check and fix your own systems.

The “store now, decrypt later” attack

In a “store now, decrypt later” attack, the attacker does not need to break your session today. The attack has two phases, and there can be many years between them. Some people also call it “harvest now, decrypt later”.

In the first phase, the attacker records encrypted traffic. Any party with access to the network path can do this: an internet provider, a compromised router, or a state agency on a backbone link. The attacker cannot read the data yet, and does not need to. Storage is cheap, so the attacker can keep the recording for many years.

In the second phase, a quantum computer that is large enough to attack real cryptography becomes available. Researchers call this a cryptographically relevant quantum computer (CRQC). The attacker uses it to break the key exchange of each recorded session. With the session key, the attacker decrypts the full session.

Figure 1. The two phases of a “store now, decrypt later” attack.

Think about what goes through a typical SSH session. Engineers type sudo passwords. They copy private keys with scp. They open configuration files that contain database connection strings and API tokens. Some of these secrets will still be valid in ten years. Others show the design of your internal network.

Michele Mosca, a researcher in quantum computing, gave a simple rule to decide if you must act now. Let x be the number of years your data must stay secret. Let y be the number of years that you need to move to new cryptography. Let z be the number of years until a CRQC exists. If the condition below is true, you are already late:

x + y > z

Nobody knows the value of z. But for many secrets, x is long. In a large organization, y is also long. For this reason, the safe decision is to protect your traffic now, before somebody records it.

Why key exchange is the weak point

The privacy of an SSH session depends on one step: the key exchange. If an attacker breaks this step, they get the session keys. After that, the encryption gives no protection.

This is the sequence when a client connects to a server:

1. The client and the server send their version strings, for example SSH-2.0-OpenSSH_10.0.
2. Each side sends a KEXINIT message with its list of supported algorithms. The connection uses the first key exchange algorithm in the client's list that the server also supports.
3. The client sends its ephemeral public value. The server replies with its own value, its host public key, and a signature.
4. Each side calculates the same shared secret from the two values. Both sides derive the session keys from this secret.
5. The two sides send NEWKEYS. From this point, all traffic is encrypted, including the user login.

Figure 2. The SSH connection setup. Steps 3 and 4 are the key exchange.

The ephemeral values in step 3 travel in clear text. This is safe against a classical computer, because it cannot calculate the shared secret from the public values in a practical time. The security depends on a hard mathematical problem: the discrete logarithm on an elliptic curve (X25519) or in a finite field (classic Diffie-Hellman).

The ephemeral keys also give forward secrecy. If an attacker steals the server’s host key next year, they still cannot decrypt old sessions. But forward secrecy does not help against a quantum computer. The public values are in the recording. A quantum computer can calculate the shared secret directly from them.

What quantum computers can and cannot break

A quantum computer does not break all cryptography. It breaks public-key cryptography that depends on factoring or on discrete logarithms. Two quantum algorithms are important here.

Shor’s algorithm solves factoring and discrete logarithms in polynomial time. These are the hard problems behind RSA, Diffie-Hellman, X25519, ECDSA and Ed25519. With a CRQC, an attacker can calculate a private key from its public key.

Grover’s algorithm speeds up a brute-force search. In theory, it cuts the effective length of a symmetric key in half. A 256-bit key gives about 128 bits of security against a quantum attacker. This is still very strong. Grover’s algorithm is also difficult to run in parallel, so a real attack is slower than the theory.

Algorithm type                Use in SSH                 Attack  Result
----------------------------  -------------------------  ------  ------
X25519, ECDH, Diffie-Hellman  Key exchange               Shor    Broken
RSA                           Host keys, user keys       Shor    Broken
ECDSA, Ed25519                Host keys, user keys       Shor    Broken
ChaCha20, AES-256             Session encryption         Grover  Safe
SHA-256, SHA-512              Key derivation, integrity  Grover  Safe

Table 1. The effect of a quantum computer on the algorithms that SSH uses.

The table shows the important point. The session ciphers are not the problem. The first cipher in the OpenSSH default list is chacha20-poly1305, and it uses a 256-bit key. The problem is the classical key exchange that creates the key for this cipher.

Signatures versus key exchange

The table above shows that Shor’s algorithm also breaks RSA, ECDSA and Ed25519. SSH uses these algorithms for host keys and user keys. So why does OpenSSH focus on the key exchange first?

The answer is time. A signature protects a session only at the moment of the connection. The server signs the handshake, and the client checks the signature immediately. An attacker who breaks this signature in 2035 cannot go back to 2026 and change a handshake that is already complete. So a recording of the session does not help a future signature attacker.

The key exchange is different. Its output protects the content of the session, and the content stays in the recording forever. For this reason, the OpenSSH post-quantum page says that broken signatures are no risk for traffic that was already sent.

Signatures still need a migration, but the deadline is different. You must replace classical host keys and user keys before a CRQC exists. After that day, an attacker can forge a host key signature and do a live man-in-the-middle attack. The key exchange must change before the attacker starts to record. The signatures must change before the attacker has the quantum computer.

Post-quantum key exchange in OpenSSH

OpenSSH did not wait for the quantum computer. It has used a post-quantum key exchange by default since version 9.0, released in April 2022. Today it supports two post-quantum algorithms.

sntrup761x25519-sha512 uses Streamlined NTRU Prime, a lattice-based algorithm. OpenSSH selected it in 2022, before NIST finished its standardization process. The first name of this algorithm had the suffix @openssh.com. Version 9.9 added the IANA-registered name without the suffix. Both names select the same algorithm.

mlkem768x25519-sha256 uses ML-KEM-768. NIST published ML-KEM as the standard FIPS 203 in August 2024. It comes from the CRYSTALS-Kyber design. OpenSSH added it in version 9.9 and made it the default in version 10.0. The release notes of version 10.0 give these reasons: ML-KEM is a NIST standard, it is never weaker than the classical curve25519-sha256, and it is faster than sntrup761.

The post-quantum parts of both algorithms, ML-KEM and Streamlined NTRU Prime, are key encapsulation mechanisms (KEMs). A KEM works differently from Diffie-Hellman. The client makes a key pair and sends the public key. The server makes a random secret, locks it with the public key, and sends the result (the ciphertext). Only the client can unlock the ciphertext with its private key. After this step, the two sides have the same secret.

Figure 3. Post-quantum milestones in OpenSSH.

The important version numbers are easy to remember. Version 9.0 or later supports sntrup761. Version 9.9 or later supports ML-KEM. If both the client and the server run version 9.0 or later with default settings, the connection is already protected. You do not need to change anything.

The hybrid design

Look again at the algorithm names. Each name has two parts: mlkem768 and x25519, or sntrup761 and x25519. All post-quantum key exchanges in OpenSSH are hybrids. They run a post-quantum algorithm and the classical X25519 algorithm in parallel, and then they combine the two results.

In mlkem768x25519-sha256, each side calculates two shared secrets: one from ML-KEM and one from X25519. Then each side puts the two secrets together and calculates a SHA-256 hash of them. This hash is the final shared secret. The session keys come from it.

Figure 4. A hybrid key exchange combines two secrets into one.

To get the final secret, an attacker must break both algorithms. A quantum computer can break X25519, but no known attack breaks ML-KEM. A classical computer cannot break either of them.

Why keep the classical part? Post-quantum algorithms are young, and young algorithms sometimes fail. SIKE is a good example. It was a candidate in the NIST process. In 2022, two researchers, Wouter Castryck and Thomas Decru, broke it with a normal computer in about one hour. If a new attack breaks ML-KEM one day, the X25519 part still protects your sessions against classical attackers. For this reason, a hybrid exchange is never weaker than the old curve25519-sha256.

The cost is small. An X25519 public value is 32 bytes. An ML-KEM-768 public key is 1,184 bytes, and its ciphertext is 1,088 bytes. The handshake becomes approximately 2 KB larger, and this happens only one time per connection. For SSH, this difference is not important.

Hands-on: check your connections

Do not guess which algorithm your connections use. You can check it in a few seconds.

Step 1. Find the client version.

ssh -V

Step 2. Find the key exchange of a real connection. Use verbose mode and look for the kex: algorithm line:

ssh -v user@server.example.com exit 2>&1 | grep "kex: algorithm"

A protected connection shows a post-quantum algorithm:

debug1: kex: algorithm: mlkem768x25519-sha256

If you see curve25519-sha256 or diffie-hellman-group14-sha256, the session uses only classical cryptography. The same verbose output also shows the server version in the line that starts with Remote protocol version.

Get Arash Zand’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Step 3. List the algorithms that your client supports.

ssh -Q kex

Step 4. Show the effective client settings for one host. This command reads all your configuration files and shows the final result:

ssh -G server.example.com | grep -i kexalgorithms

Step 5. Show the effective server settings. Run this command on the server:

sudo sshd -T | grep -i kexalgorithms

Step 6. Check many servers. The key exchange occurs before authentication. For this reason, the script below works even when you do not have a login on the host. The -n option stops ssh from reading the host list from standard input:

#!/usr/bin/env bash
# Prints the negotiated key exchange algorithm for each host in hosts.txt
while read -r host; do
  kex=$(ssh -n -o BatchMode=yes -o ConnectTimeout=5 -v "$host" exit 2>&1 \
        | grep -m1 "kex: algorithm:" | awk '{print $NF}')
  echo "$host ${kex:-no-answer}"
done < hosts.txt

From outside the network, you can also use nmap --script ssh2-enum-algos -p 22 <host>. This command shows all the algorithms that the server offers, not only the selected one.

Configure the client and the server

The best configuration is often no configuration. The defaults of a modern OpenSSH are good. Some teams lose post-quantum protection because of an old hardening guide. Older guides often tell you to set a fixed KexAlgorithms list, for example:

KexAlgorithms curve25519-sha256,diffie-hellman-group16-sha512

This line was good advice before 2022. Today, it disables the post-quantum algorithms, even on the newest OpenSSH. Search your configuration files and your configuration management code (Ansible, Puppet, Terraform templates) for KexAlgorithms.

Client configuration. If you must have an explicit list, put the post-quantum algorithms first. The ^ character puts the given algorithms at the start of the default list. Put the Host * block at the end of the file, because the first value for a keyword wins:

# ~/.ssh/config
Host *
    KexAlgorithms ^mlkem768x25519-sha256,sntrup761x25519-sha512

For servers that you control, you can enforce post-quantum only. If the server cannot agree, the connection fails. This is a good way to find old servers:

Host *.internal.example.com
    KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512

On the client and on the server, use only names that ssh -Q kex shows. An older version stops with a configuration error when it finds an unknown name. For example, OpenSSH 9.0 to 9.8 knows sntrup761 only with the @openssh.com suffix.

Server configuration. On the server, put the line in /etc/ssh/sshd_config or in a file under /etc/ssh/sshd_config.d/:

KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,sntrup761x25519-sha512@openssh.com,curve25519-sha256

The curve25519-sha256 entry at the end keeps old clients working. Remove it when all your clients support a post-quantum algorithm.

In both files, the first value for a keyword wins. Many Linux distributions include the sshd_config.d directory at the top of the main file. So a value in a drop-in file replaces a value later in the main file. Always test the syntax and check the effective value before you reload:

sudo sshd -t && sudo sshd -T | grep -i kexalgorithms
sudo systemctl reload ssh    # the service name is "sshd" on some distributions

Keep your current session open while you reload. If the new configuration fails, you can still fix it.

The warning. The WarnWeakCrypto option controls the new warning. For an old device that you cannot upgrade, you can disable it for that host only:

Host legacy-switch.example.com
    WarnWeakCrypto no

Do not disable it for Host *. OpenSSH can use this option for other weak-cryptography warnings in the future, and a global setting hides those warnings too.

Migration plan for real systems

One laptop and one server are easy. A company has hundreds of SSH endpoints, and many of them are not Linux servers. Use a simple process for each endpoint.

Figure 5. A decision flow for each SSH endpoint.

Make an inventory. Use the script from the hands-on section on all known hosts. Do not forget these endpoints:

• Network devices, such as switches, routers and firewalls. Their SSH implementation often comes from the vendor and changes slowly.
• Storage systems, hypervisors and other appliances.
• SFTP connections to partners and banks.
• CI/CD runners that deploy with SSH, and Git connections over SSH.
• Windows machines. The built-in OpenSSH on Windows can be older than the Linux packages.
• Application code that uses an SSH library, for example SSH.NET, Paramiko, JSch, libssh or Go’s x/crypto/ssh. The library does the key exchange, not the system OpenSSH.

Set priorities. Start with traffic that crosses networks that you do not control: the internet, partner links and cloud interconnects. Then continue with sessions that carry long-lived secrets, such as key distribution and database administration.

Test the libraries. For application code, the easiest test is an integration test. Start an OpenSSH server in a container and set its KexAlgorithms to post-quantum algorithms only. If your application can connect, its library supports a post-quantum key exchange. If it cannot connect, you found a gap before production did.

Isolate what you cannot upgrade. Some devices will never get new firmware. Put them behind a jump host that runs a modern OpenSSH, and use ProxyJump. The outer session from your laptop to the jump host uses a post-quantum key exchange. On that path, the old inner session travels inside the protected tunnel. The short path from the jump host to the device is still classical, so keep that path on an isolated management network.

What comes next

Now that the key exchange is solved, OpenSSH works on signatures. In version 10.1, the project removed XMSS, an older experimental post-quantum signature scheme. In version 10.4, released in July 2026, it added experimental support for ssh-mldsa44-ed25519@openssh.com.

This new signature type follows the same idea as the key exchange. It is a hybrid. ML-DSA-44 (from the NIST standard FIPS 204) and Ed25519 both sign the same message. A verifier accepts the signature only if both parts are valid.

In version 10.6, released on 6 October 2026, OpenSSH enabled this hybrid signature algorithm. If you made keys with the experimental support in 10.4, you must make new keys or remove the old ones.

My recommendation for the next step is simple. Test the new key type in a lab first. Check that your clients, servers, jump hosts and libraries all accept it. If you use an SSH certificate authority, plan the rotation through it, because a CA makes key changes much easier than manual authorized_keys files. You have more time for signatures than for the key exchange, but a full key rotation in a large company takes years.

Conclusion and checklist

A quantum computer that breaks SSH does not exist today. The recordings that it will decrypt can exist today. That is the full message of the new OpenSSH warning. The good news is that the fix is already in your package manager, and on most modern systems it is already active.

Use this checklist for your own systems:

• Run ssh -V and confirm that your clients use OpenSSH 10.0 or later. Version 9.0 is the minimum for a post-quantum key exchange.
• Run ssh -v <host> exit and confirm that the key exchange is mlkem768x25519-sha256 or sntrup761x25519-sha512 (with or without the @openssh.com suffix).
• Search your configuration files and automation code for old KexAlgorithms lists.
• Upgrade servers, jump hosts and CI/CD runners that still use a classical key exchange.
• Make a list of network devices and appliances that you cannot upgrade, and put them behind a modern jump host.
• Add an integration test that checks post-quantum support in your SSH libraries.
• Disable the warning only per host, never for Host *.
• Start a lab test of hybrid post-quantum host keys and user keys.

If you see the warning tomorrow, do not ignore it and do not hide it. Use it as a free inventory tool. Each warning shows you one connection that an attacker can record today and read later.

References

• OpenSSH: Post-Quantum Cryptography
• OpenSSH 10.6 release notes
• Help Net Security: OpenSSH 10.4 released
• Help Net Security: OpenSSH 10.6 released
• NIST FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard (August 2024)
• NIST FIPS 204, Module-Lattice-Based Digital Signature Standard (August 2024)