up:: In the Protocols MOC

Secure Shell (SSH)

SSH (Secure Shell) is the protocol that secures remote administration, file transfer, and port forwarding across effectively all server infrastructure, giving an operator an encrypted, authenticated channel into a machine over an untrusted network. Every SSH session does two cryptographic jobs at once: it runs a key exchange to establish the secret keys that encrypt the session, and it authenticates both ends with digital signatures so the client knows it’s reaching the right server and the server knows it’s admitting the right account. The quantum problem with SSH isn’t that the protocol is broken. Its key exchange (classical ECDH or Diffie-Hellman) and its authentication keys (RSA, ECDSA, Ed25519) rest on math a large quantum computer can solve, so the fix is to swap those pieces for quantum-safe ones while keeping SSH itself.

The short version:

• SSH bundles two separable cryptographic jobs into one connection, key exchange for confidentiality and signature-based authentication for identity, and each faces the quantum threat on a different clock.
• The key exchange is the urgent piece. It’s what a harvest-now-decrypt-later attacker targets, because a session recorded today can be decrypted once a quantum computer arrives.
• The host and user authentication keys are the slower track. Forging a signature needs a quantum computer live at connection time, so there’s nothing to harvest, which buys migration time.
• The way SSH goes quantum-safe is hybrid key exchange, running classical X25519 and ML-KEM together so the session holds as long as either half survives. This is the mature, deployable move today; post-quantum signatures are early and experimental.
• A connection is only as quantum-safe as the weaker of its two endpoints, so the migration is a fleet-wide rollout, and an old jump host or appliance that can’t negotiate the hybrid silently drags the session back to classical key exchange.

Think of SSH as a locked room with two separate guarantees. One is the lock on the door that keeps anyone outside from watching what happens inside, and the other is the ID check at the entrance that proves the person at the door is who they claim to be. Quantum computing threatens both locks, but on different schedules.

Someone can photograph the encrypted door lock today and pick it years later once the right tool exists, so that lock has to change first. The ID check only helps an intruder in the moment, so its quantum-proof replacement can follow. You don’t tear down the room. You upgrade the door lock now and the ID check when its replacement is ready.

What is SSH?

SSH is a cryptographic protocol for secure remote login and other secure network services over an insecure network, and it’s the backbone of remote server administration and automated deployment across nearly every Unix, Linux, macOS, and Windows system. When an administrator opens a shell on a remote host, a CI/CD pipeline pushes to a server, or a file moves over scp or sftp, SSH is almost always the protocol carrying it. The version in use everywhere is SSH-2, the redesigned second-generation protocol that replaced the original SSH-1.

SSH-2 is specified across four IETF RFCs published in January 2006, which together define the protocol suite:

1. RFC 4251 defines the overall SSH protocol architecture.
2. RFC 4252 defines the authentication protocol (how a user proves identity).
3. RFC 4253 defines the transport layer protocol, where the key exchange, encryption, and integrity protection live. This is the RFC that governs the confidentiality channel.
4. RFC 4254 defines the connection protocol (channels, port forwarding, tunneling).

The important thing to hold onto is the same structural point that governs TLS: SSH is a framework that negotiates several separate cryptographic functions per session, not one fixed algorithm. Client and server exchange lists of supported algorithms and agree on the best common choice for key exchange, host-key signature, symmetric cipher, and message authentication. Because those are independent negotiations, “is SSH quantum-safe?” has no single answer. The honest question is which mechanism is doing each job in a given deployment, because each one faces the quantum threat differently.

Source: T. Ylonen, C. Lonvick (Ed.), “The Secure Shell (SSH) Transport Layer Protocol,” RFC 4253, January 2006, datatracker.ietf.org.

Source: T. Ylonen, C. Lonvick (Ed.), “The Secure Shell (SSH) Protocol Architecture,” RFC 4251, January 2006, datatracker.ietf.org.

Where does cryptography live in an SSH session?

Cryptography in SSH lives in two places, and only one of them carries the harvestable quantum exposure. Keeping them apart is the whole game.

Key exchange runs first, at the transport layer (RFC 4253). The client and server each contribute a public value, combine it with their own private value, and compute the same shared secret without that secret ever crossing the wire. That shared secret is run through a key-derivation function to produce the symmetric session keys. Every keystroke, file, and tunneled connection after that is encrypted and integrity-protected under those keys. Modern SSH key exchange has usually been curve25519-sha256 (elliptic-curve Diffie-Hellman over Curve25519) or an ecdh-sha2-nistp* or diffie-hellman-group* variant. This is the confidentiality promise, selected by the KexAlgorithms setting.

Authentication runs on digital signatures and answers “who is each side?” It has two halves:

1. The host key proves the server is the right machine. The server signs the handshake with its host private key, and the client checks that signature against a fingerprint it already trusts (the known_hosts file, or a certificate signed by an SSH certificate authority). This is what stops a man-in-the-middle from impersonating the server.
2. The user key proves the client is an authorized account, typically through public-key authentication (RFC 4252). The most common host and user key types are ssh-ed25519 (Ed25519), ecdsa-sha2-nistp* (ECDSA), and ssh-rsa / rsa-sha2-* (RSA).

The reason this split is load-bearing is that only the key-exchange channel carries harvest-now-decrypt-later risk. OpenSSH’s own post-quantum guidance draws the line plainly: an attacker “may collect encrypted SSH sessions now and then decrypt them later once they have access to a quantum computer,” whereas for the authentication signatures “there is no analogous ‘store now, decrypt later.‘” A forged login can’t be executed against a session that already happened.

Source: OpenSSH, “Post-Quantum Cryptography,” openssh.com/pq.html.

Source: T. Ylonen, C. Lonvick (Ed.), “The Secure Shell (SSH) Authentication Protocol,” RFC 4252, January 2006, datatracker.ietf.org.

Which parts of SSH are quantum-vulnerable?

Two of the three cryptographic roles in SSH are quantum-vulnerable, and they’re vulnerable on very different clocks. Getting the difference right is what tells you what to fix first.

Key exchange is the urgent piece. SSH key exchange based on ECDH (including Curve25519), NIST-curve ECDH, or classical Diffie-Hellman produces a shared secret that Shor’s Algorithm can recover on a large enough quantum computer. The reason it’s urgent is timing. An adversary can record SSH handshakes and encrypted sessions today, store them, and decrypt them years later once a capable quantum computer exists. That’s harvest-now-decrypt-later, and it puts any long-lived secret that ever crossed an SSH session (source code, database credentials, key material, tunneled internal traffic) at risk right now, well before the quantum computer boots up.

Host and user authentication keys are the slower track. The host key and user key sign with RSA, ECDSA, or Ed25519, and every one of those signature schemes is breakable by Shor’s Algorithm once a quantum computer exists. One thing that trips people up: Ed25519 is built on Curve25519, but it uses EdDSA signing, which Shor’s algorithm breaks the same way it breaks the others, so being a “25519” algorithm doesn’t make it quantum-safe.

The saving grace is that forging one of these signatures needs a quantum computer live at the moment of the connection, because a signature only matters during authentication. There’s nothing to harvest and no deferred payoff, so this is a Non-HNDL trust problem rather than a confidentiality problem. It still has to be fixed, because a CRQC-equipped attacker who derives a long-lived host private key could run silent man-in-the-middle attacks without tripping a known_hosts warning. But the clock is genuinely slower, which is why the ecosystem is moving key exchange first and signatures second.

Symmetric encryption survives. The symmetric ciphers that protect the actual session data (aes256-gcm@openssh.com, chacha20-poly1305@openssh.com) aren’t broken by Shor’s algorithm. Their only quantum concern is Grover’s Algorithm, which speeds up brute-forcing a key but is defeated by using a large one. A 256-bit key such as AES-256 keeps a comfortable margin, so the data channel of SSH is a keep-and-strengthen item, not a replacement.

SSH role	The algorithm today	Quantum threat	Exposure class	Urgency
Key exchange	ECDH / Curve25519 / DH	Broken by Shor’s	HNDL, harvestable today	Highest, migrate first
Host and user keys	RSA / ECDSA / Ed25519	Broken by Shor’s	Non-HNDL, needs a live CRQC	Slower track
Session encryption	AES-GCM / ChaCha20-Poly1305	Weakened by Grover’s	Retain and strengthen	Use AES-256, no swap

Sources: P. W. Shor, “Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer,” SIAM J. Comput. 26(5), 1997, arxiv.org.

Source: OpenSSH, “Post-Quantum Cryptography,” openssh.com/pq.html.

How does SSH go post-quantum?

SSH goes quantum-safe in two moves, and the ordering follows the two clocks from the vulnerability section: fix the harvestable key exchange first, fix the authentication signatures later.

Move one, hybrid key exchange. Rather than ripping out classical key exchange and trusting a young algorithm alone, SSH runs a classical and a post-quantum key exchange together in one handshake and mixes both results into the session secret. The primary quantum-resistant construction is mlkem768x25519-sha256, which combines classical X25519 with ML-KEM-768, NIST’s standardized lattice-based key-encapsulation mechanism.

The session is safe if either half holds: if ML-KEM turns out to have a flaw, X25519 still defends against a classical attacker, and if a quantum computer arrives, ML-KEM still defends against it. This is the hybrid pattern, the same defining move the TLS ecosystem made, and it removes the HNDL exposure without betting everything on a new scheme. Because SSH negotiates the key-exchange algorithm at the transport layer, gaining the hybrid is a matter of running a capable build on both ends, with no application change. The hybrid has been shipping on by default in OpenSSH since it made mlkem768x25519-sha256 the negotiated default in release 10.0 (April 2025).

Move two, post-quantum authentication signatures. The host-key and user-key side transitions later, toward NIST’s standardized signature schemes, ML-DSA as the general-purpose choice, with hash-based options where a conservative signature is preferred. This is harder to roll out than key exchange because it touches the entire authentication chain, every known_hosts fingerprint, every SSH certificate authority, and every peer that has to accept a new key type, so it moves on a longer timeline.

As of mid-2026 this side is early and experimental. OpenSSH’s guidance is that it “will add support for post-quantum signature algorithms in the future,” and the first experimental composite signature type only just landed in a recent release. Post-quantum SSH authentication is a capability to watch and pilot, not to deploy in production.

The implementation specifics, the exact release-by-release timeline, the config knobs, the FIPS-validation caveats, and the experimental signature type, live in the OpenSSH note, since OpenSSH is the dominant SSH implementation and its posture is effectively the SSH control plane’s posture.

Sources: NIST, “Module-Lattice-Based Key-Encapsulation Mechanism Standard,” FIPS 203, August 2024, csrc.nist.gov.

Source: OpenSSH, “Post-Quantum Cryptography,” openssh.com/pq.html.

What does migrating SSH actually look like?

Migrating SSH is a fleet-wide rollout tracked endpoint by endpoint, not a single switch, because of one rule that governs everything: a connection is only as quantum-safe as the weaker of its two endpoints. Both the client and the server have to support the hybrid key exchange for a session to negotiate it, so the real work is getting a capable build across a very large, mixed population of endpoints, many of them owned by vendors rather than by whoever owns the data.

The reality has a few defining features:

1. The weakest-endpoint rule. If a modern client supports mlkem768x25519-sha256 but the server it reaches doesn’t, the handshake falls back to classical key exchange and the HNDL exposure stays open. Coverage, not capability, is what closes the exposure.
2. Jump hosts and bastions negotiate down. A bastion or jump host sits in the path of every session routed through it, so if it runs an old build that can only speak classical key exchange, it drags every downstream connection back to a quantum-vulnerable exchange even when both real endpoints are modern. High-traffic intermediaries are the highest-leverage endpoints to upgrade first.
3. Vendor-frozen builds are the real blocker. A large share of SSH endpoints are network appliances, embedded management planes, storage controllers, and IoT gateways running older or vendor-locked SSH builds. Those inherit the vendor’s firmware cadence, not the upstream release cadence, so slow firmware cycles are where the SSH transition actually stalls.
4. Visibility takes configuration-level inspection. The presence of SSH tells you nothing about which key-exchange group a given endpoint actually negotiates, and what a server merely permits as a fallback can differ from what a scan sees on one live handshake. Seeing the true cryptographic posture means reading the server configuration (sshd_config KexAlgorithms, HostKeyAlgorithms) and version banners, which is the evidence layer a cryptographic bill of materials is built to capture.

One thing that makes SSH more tractable than TLS: algorithm negotiation is entirely between the client and the server, with no external certificate-authority ecosystem in the loop for the key-exchange move. When both ends support the hybrid, the negotiation selects it automatically, so key-exchange migration can proceed incrementally, endpoint by endpoint, without waiting on anyone outside the organization. The whole effort is a crypto-agility problem underneath: endpoints that can negotiate new key-exchange algorithms and retire old ones through a routine upgrade migrate cleanly, while endpoints hard-wired to one frozen build have to be replaced or re-flashed first.

What are the interop and deployment traps?

The main traps in an SSH migration are silent fallback and frozen endpoints, not protocol breakage. Unlike the oversized-ClientHello problem that bites post-quantum TLS, SSH’s larger post-quantum key-exchange messages ride inside the already-negotiated SSH transport framing, so packet-size middlebox failures are less of a headline. The failure modes that actually matter here are about coverage:

1. Silent downgrade to classical key exchange. The hybrid only negotiates when both ends support it, and the fallback to classical ECDH is designed to be seamless, which is exactly the danger. A session that quietly fell back looks identical to a healthy one but carries full HNDL exposure. Newer OpenSSH builds added a warning when a non-post-quantum key agreement is negotiated precisely to make that fallback visible to operators.
2. Mixed client and server versions. A fleet is rarely uniform. A capable server still gets classical-only sessions from old clients (developer laptops, CI runners, monitoring agents), and a capable client still falls back when it reaches a frozen server. The migration isn’t done until both sides of the connections that matter are on capable builds.
3. Agent forwarding widens the surface. SSH agent forwarding exposes a user’s authentication key material to intermediate hops. While authentication is the slower quantum track, forwarding still spreads the endpoints where a key is handled, which matters for the eventual signature migration and for present-day hygiene.
4. Patching hygiene and quantum posture overlap. An endpoint stuck on an old build to avoid the hybrid is usually also behind on routine security patches, so the same frozen appliance is often both quantum-exposed on key exchange and carrying known non-quantum vulnerabilities. Upgrading fixes both at once.

Common misconceptions

• “SSH is broken by quantum computers.” The protocol isn’t broken. Two public-key pieces inside it (the key exchange and the authentication signatures) are, and the fix is to swap those mechanisms while keeping SSH. The symmetric encryption of the session data is fine.
• “SSH isn’t post-quantum yet.” Its key exchange has been post-quantum by default in OpenSSH since it made the ML-KEM hybrid the default in release 10.0 (April 2025). The confidentiality channel is one of the most quantum-ready pieces of common infrastructure.
• “The authentication keys are the urgent problem.” It’s the reverse. Host and user signatures need a quantum computer live at connection time, so there’s nothing to harvest. Key exchange is harvestable today, which makes it the piece to migrate first.
• “Ed25519 keys are quantum-safe because they use Curve25519.” Ed25519 signs with EdDSA, which Shor’s Algorithm breaks like any other elliptic-curve signature. Sharing a curve with X25519 key exchange doesn’t make the signature quantum-resistant.
• “Upgrading one server is enough.” The hybrid only negotiates when both endpoints support it, so a capable server talking to a legacy client, or a modern client reaching an old jump host, still falls back to classical key exchange. The migration is fleet-wide.
• “Enabling the hybrid is one config flag and we’re done.” The flag is the easy part. A session only goes hybrid if both ends support the algorithm, so the real work is coverage across every server, client, bastion, and vendor-controlled appliance in the path.

Questions people ask

What actually changes in SSH for post-quantum? The key-exchange step changes first, from classical ECDH or Curve25519 to a hybrid (mlkem768x25519-sha256) that runs classical X25519 and ML-KEM together and mixes both into the session secret. The host and user authentication signatures change later, toward ML-DSA. The symmetric encryption of the session data stays the same, ideally at AES-256 strength.

Do I have to change my applications or scripts? No. SSH negotiates the key-exchange algorithm at the transport layer, so getting the hybrid is a matter of running a capable SSH build on both ends, with no change to application code or scripts. You only touch config if you want to force or restrict which algorithms are allowed.

What’s hybrid key exchange, in one line? Running a classical and a post-quantum key exchange in the same handshake and mixing both into the session secret, so the session stays secure as long as either one holds. It’s the safety net that lets SSH adopt a young post-quantum algorithm without betting everything on it.

Is post-quantum SSH ready to deploy today? For key exchange, yes. The mlkem768x25519-sha256 hybrid is standardized on ML-KEM and has been the OpenSSH default since release 10.0 (April 2025), so getting to a current build closes the harvest-now-decrypt-later window on the session. Post-quantum authentication is early and experimental, so it’s a capability to pilot, not to roll out.

Which is more urgent, the key exchange or the host keys? Key exchange, clearly. It’s harvestable today under HNDL, so a session recorded now is a future liability. Host and user signatures are Non-HNDL, since a forged login can’t be run retroactively, so they’re a real but slower-clock problem.

What about SSH on network appliances and embedded devices? Those usually run a vendor-controlled SSH build, so they inherit the vendor’s firmware timeline rather than the upstream release cadence. That’s where the SSH transition tends to stall, because the operator can’t drive the upgrade directly and has to manage it as a vendor dependency, and jump hosts or appliances stuck on old builds pull downstream sessions back to classical key exchange.

Why can a session silently fall back to a vulnerable key exchange? Classical key-exchange algorithms stay negotiable for backward compatibility, so when one end can’t do the hybrid, the handshake quietly settles on the classical algorithm both ends share. The session still works and looks normal, which is why the thing that closes the exposure is coverage across every endpoint rather than enabling the algorithm in one place.

---

Everything here is the map, given freely. When your team needs its SSH fleet, bastion hosts, and vendor-controlled appliances assessed for where the quantum-resistant key exchange is actually negotiating and where it’s silently falling back to classical, that’s the work I do, and there’s an alignment briefing for it.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.