Notifications
Clear all
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.
NHIMG editorial — based on content published by Cybertrust Japan: SSH post-quantum key exchange and hybrid negotiation on AlmaLinux 10.1
Questions worth separating out
Q: How should teams implement post-quantum SSH without breaking existing access paths?
A: Start with hybrid key exchange on the most important administrative and automation paths, then test client and server combinations for silent fallback.
Q: Why do SSH sessions matter in store now, decrypt later risk?
A: SSH often carries privileged commands, configuration changes, and file transfers that remain valuable long after the session ends.
Q: What do security teams get wrong about PQC readiness in SSH?
A: Teams often confuse package availability with real-world protection.
Practitioner guidance
- Inventory negotiated SSH key exchanges Test representative client and server pairs to confirm which algorithm is actually selected during connection establishment, then record where mlkem768x25519-sha256 is used and where fallback still occurs.
- Prioritise long-retention SSH paths Classify SSH flows by the sensitivity and shelf life of what they carry, including admin sessions, file transfers, and automated change channels, then move the highest-retention paths first.
- Align client and server policy files Review distro-specific crypto policy back-ends and SSH configuration inheritance so that both ends of the connection permit the same hybrid suite and do not silently downgrade to classical exchange.
What's in the full article
Cybertrust Japan's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step verification commands for checking the negotiated SSH key exchange on Linux, macOS, and Windows clients
- Distribution-by-distribution results showing which OpenSSH versions and policy defaults actually enable mlkem768x25519-sha256
- Example debug output that helps administrators confirm whether PQC or classical exchange was chosen in a live session
- Configuration notes for handling non-PQC warnings and suppressing weak-crypto alerts where appropriate
👉 Read Cybertrust Japan's analysis of SSH post-quantum key exchange on AlmaLinux 10.1 →
SSH post-quantum key exchange: are hybrid controls ready yet?
Explore further
10/07/2026 9:34 pm
Hybrid cryptography is the pragmatic bridge, not the end state. The article shows that organisations do not need to wait for a full post-quantum ecosystem before taking action, because hybrid SSH already lets teams layer PQC with classical trust. That is the right transition model for regulated and operationally complex environments, where compatibility still matters. The governance mistake is to treat support as binary when the real control is negotiated algorithm choice. Practitioners should measure what is actually negotiated, not what is merely available.
A question worth separating out:
Q: Who should own SSH post-quantum migration in an enterprise?
A: Ownership should sit with the teams that govern privileged access, remote operations, and machine-to-machine trust, because SSH is part of identity and access control in practice. Security architecture can define the standard, but platform and IAM teams need to enforce policy, validate negotiation, and track fallback across the estate.
👉 Read our full editorial: SSH post-quantum key exchange shows the hybrid transition path
