The OpenSSH 10.x series ships with hybrid post-quantum key exchange as the preferred default. For most Indian estates on modern Debian, Ubuntu LTS or RHEL derivatives the upgrade is uneventful. The interesting work is on the edges: legacy jumphosts, embedded appliances, regulated bastions, and the slower PQ migration for TLS and IPSec that this release foreshadows.
What changed
OpenSSH 9.0 introduced sntrup761x25519-sha512 as an opt-in hybrid kex. 9.9 added the NIST-standardised mlkem768x25519-sha256. With the 10.x line, both hybrids now sit at the top of the default KexAlgorithms list, ahead of curve25519-sha256 and the ECDH variants. Two consequences. When both peers are recent enough, the session is protected against a future quantum attacker harvesting the handshake today and breaking it later. When the server is too old to offer either hybrid, the client emits a visible warning and falls back to classical ECDH — no hard failure, which is the right call for an ecosystem mid-migration.
What the warning looks like
** 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.htmlThe warning is informational, not fatal. If it appears suddenly after a workstation upgrade, the server is the laggard. Treat it as a ticket, not an outage.
Server-side fix
- Upgrade sshd to OpenSSH 9.9 or newer. Debian 12 / Ubuntu 24.04:
sudo apt update && sudo apt install openssh-server. RHEL 9 / Alma 9 / Rocky 9:sudo dnf upgrade openssh-server. FreeBSD 14:pkg upgrade openssh-portable. - Pin an explicit kex order in
/etc/ssh/sshd_configso a future distro change does not silently demote you:KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256,[email protected] - Restart with
sudo systemctl reload sshdand confirm the offered list withssh -Q kexfrom a client. - For appliances stuck on OpenSSH 8.x (network gear, storage controllers, older bastions), front them with a modern jumphost rather than exposing them directly. The hop adds latency, not risk.
Compatibility matrix
| OpenSSH version | PQ kex support | Notes |
|---|---|---|
| 10.x | mlkem768x25519-sha256 + sntrup761x25519-sha512, both preferred by default | Target state. Warns when peer cannot do PQ. |
| 9.9 | Both hybrids supported, mlkem768 added | Safe upgrade floor for production fleets. |
| 9.0 – 9.8 | sntrup761x25519-sha512 only | Hybrid available but not default in 9.0 – 9.5. |
| 8.x | None | Classical kex only. Triggers the client warning. Plan an upgrade. |
| 7.x and earlier | None; also missing modern MACs | End of life. Replace, do not patch. |
What about TLS, IPSec, VPNs?
SSH is the easy front of the migration because the protocol negotiates a fresh symmetric key per session and there is one well-maintained reference implementation. The rest of the stack is moving more slowly. TLS 1.3 has IETF drafts for X25519MLKEM768 hybrid groups, and OpenSSL 3.5, recent NGINX builds, AWS and Cloudflare edges are rolling support out through 2026. IPSec/IKEv2 has RFC 9370 for hybrid kex, with strongSwan and Libreswan tracking it. S/MIME and CMS are slower — ML-DSA and SLH-DSA still need PKI vendor and CA hierarchy work. The sensible move for Indian estates is to inventory long-lived ciphertext (offsite backups, archived email, log buckets) and treat that as the real store-now-decrypt-later target. SSH session traffic is short-lived; the data you wrote to S3 three years ago is not.
References
- RingSafe quantum computing track and PQ migration primer
- OpenSSH project — post-quantum key exchange notes
- NIST cybersecurity programme and PQC standards (FIPS 203/204/205)
- RingSafe India compliance programme — RBI, SEBI, IRDAI, DPDP, CERT-In
Get a DPDP gap assessment
Free 30-minute call. We map your data flows against DPDP §8 obligations and tell you exactly which gaps to fix first. Auditor-defensible output.