Post-quantum SSH is no longer just a subject for research papers or distant migration plans.
OpenSSH has used hybrid post-quantum key exchange by default since version 9.0. Version 10.0 switched the default to mlkem768x25519-sha256, combining ML-KEM with the established X25519 algorithm.
This protects against a real long-term risk.
An attacker can record encrypted SSH traffic today and keep it until more powerful technology becomes available. A sufficiently capable quantum computer could eventually break some of the classical cryptography used to establish those sessions.
This is commonly described as a “store now, decrypt later” attack.
Administrative SSH sessions may expose commands, credentials, internal addresses and infrastructure details that remain sensitive for years. Protecting that traffic now therefore makes sense, even though cryptographically relevant quantum computers do not yet exist.
The mistake is assuming that a stronger key exchange secures the entire SSH environment.
It does not.
Post-quantum SSH protects the connection. It cannot decide whether the person or process holding a trusted key should still have access.
What Post-Quantum SSH Protects
SSH performs several separate security tasks during a connection.
The key exchange creates the secret used to encrypt the session. Host authentication helps the client verify the server, while user authentication determines whether the connecting identity may log in.
Post-quantum key exchange addresses the first of those tasks.
OpenSSH uses hybrid algorithms rather than relying entirely on a newer post-quantum method. For example, mlkem768x25519-sha256 combines ML-KEM with X25519.
The classical component therefore continues to provide protection even if researchers later discover a serious weakness in ML-KEM.
That is valuable cryptographic engineering, but its purpose is specific.
The key exchange cannot inspect authorized_keys. It cannot identify who owns a public key, why someone added it or whether the corresponding private key remains under control.
A server may therefore negotiate a modern post-quantum session and then grant access to a key copied from an abandoned laptop.
The connection is protected. The trust decision may still be wrong.
Forgotten Keys Remain Valid
Public-key authentication is usually preferable to relying on reusable passwords, but it is not an access-management system by itself.
A public key does not know that its owner has left a project, replaced a workstation or stopped maintaining a server. It does not expire when the original reason for access disappears.
The server continues accepting it until someone removes it.
This is how temporary access quietly becomes permanent.
Keys added during migrations, emergency work or support sessions often remain long after the task has finished. Months later, the comment inside authorized_keys may be unclear and nobody can confidently identify who controls the private key.
The cryptography has not failed. The administrative process has.
Shared private keys create another problem. The server can record which key authenticated, but it cannot reliably identify the individual who used it when several people share the same credential.
For every accepted key, I want three basic answers:
- Who owns it?
- Why is it present?
- How will it be revoked?
Protecting the Private Key Is Not Enough
The location of the private key matters too.
It may still exist on an old laptop, inside a forgotten backup or on a device that no longer receives security updates.
A strong passphrase can make a stolen key file harder to use, but it cannot revoke the credential. As long as the server trusts the matching public key, the access path remains available.
Hardware-backed FIDO keys reduce the risk of silent key theft because the important key material remains inside the authenticator.
They still require ownership records and a removal process. A lost hardware token must be revoked from every system that trusts it.
Agent forwarding also deserves care.
The private key remains on the local machine, but someone with sufficient access to the intermediate server may use the forwarded agent to authenticate with identities loaded into it.
I therefore treat agent forwarding as an exception, not a global default.
Review Access Before Tuning Algorithms
Post-quantum support may tempt administrators to start by editing ssh_config or sshd_config.
That is not always the most useful first step.
OpenSSH improves its default algorithms over time. A manually maintained KexAlgorithms list can replace the defaults completely unless it uses modifiers such as +, - or ^.
An old hardening configuration may therefore prevent newer post-quantum methods from being negotiated.
Before changing algorithms, I would review the access that already exists.
Every key should have a known owner and a current purpose. Unknown entries should be investigated or removed.
Shared credentials should be replaced with individual keys, while temporary access should have a defined end.
Automation keys need the same attention.
A backup job or deployment process rarely needs an unrestricted interactive shell. Its key should receive only the commands and forwarding capabilities required for that task.
Reducing what a credential can do is often more useful than adding another line to a cryptographic configuration.
Larger environments may benefit from SSH certificates or another short-lived access model instead of distributing permanent keys across every server.
These approaches do not eliminate administration, but they can make approval and revocation easier to control.
Post-quantum SSH still matters. Traffic captured today may remain sensitive far into the future, and hybrid key exchange provides practical protection against that risk.
It simply solves a different problem.
Post-quantum cryptography protects the session from future decryption. Good key hygiene ensures that the person or process opening that session still deserves access.
A secure SSH environment needs both.