Topic starter
10/07/2026 9:11 pm
TL;DR: SSH is moving toward post-quantum key exchange through hybrid algorithms such as mlkem768x25519-sha256, but support still varies across OpenSSH versions and Linux distributions, according to Cybertrust Japan. The transition is now a practical migration issue, because store now, decrypt later risk applies to long-lived SSH traffic as well as web and API sessions.
Editorial analysis by NHI Mgmt Group, based on content published by Cybertrust Japan: “SSH ã® PQC 対å¿ï¼AlmaLinux 10.1 ã§ã®ãã¤ããªããéµäº¤æã¨å種ã¯ã©ã¤ã¢ã³ãæ¥ç¶æ¤è¨¼”.
Key questions
Q: What breaks when SSH endpoints cannot negotiate post-quantum key exchange?
A: The control breaks at negotiation time, because support on one endpoint does not guarantee hybrid protection if the peer lacks the algorithm or policy allows fallback.
Q: When should organisations prioritise post-quantum SSH over other crypto upgrades?
A: Prioritise SSH where sessions protect privileged administration, file transfer, or long-lived operational access, because those connections can be high-value targets for harvest-now, decrypt-later collection.
Q: How do security teams know SSH post-quantum controls are actually working?
A: They know it is working when representative client-server pairs consistently negotiate the hybrid algorithm and no critical paths fall back to classical Curve25519 or older KEX options.
Practitioner guidance
- Audit negotiated SSH key exchange, not just installed versions Collect handshake logs from representative clients and servers, then confirm that mlkem768x25519-sha256 is actually selected where policy expects it.
- Standardise OpenSSH baselines across endpoints Align server and client packages across Linux distributions, macOS and Windows toolchains so that hybrid negotiation is available on both sides of the connection.
- Treat fallback as a risk signal Flag any SSH session that negotiates curve25519-sha256 or another classical KEX where hybrid support is expected, because that session remains exposed to future decryption.
Bottom line: SSH post-quantum readiness is no longer just a standards discussion, because hybrid key exchange is already appearing in production stacks while older clients still fall back to classical negotiation.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
10/07/2026 9:34 pm
Hybrid SSH is a transition control, not a finished control: the article shows that post-quantum key exchange only changes security outcomes when both endpoints support it and the negotiated result is actually hybrid. That makes SSH a version-governed control surface, not a binary yes-no feature. Practitioners should treat negotiated KEX as the control evidence, not package installation alone.
A question worth separating out:
Q: What is the difference between hybrid SSH key exchange and classical SSH key exchange?
A: Hybrid SSH key exchange combines a post-quantum algorithm with a classical elliptic-curve method so that both must be broken to recover the session secret. Classical SSH key exchange relies on one cryptographic scheme, which is still operationally secure today but offers no post-quantum hedge against future decryption capability.
👉 Read our full editorial: SSH post-quantum key exchange shows the hybrid transition path