Is SSH Quantum Safe?
No. Standard SSH is not quantum safe. It typically uses RSA, ECDSA, or Ed25519 keys — all vulnerable to Shor's algorithm. OpenSSH 9.0+ supports hybrid PQC key exchange.
Key Takeaway: SSH is NOT quantum safe. Upgrade to OpenSSH 9.0+ for hybrid PQC key exchange. Regenerate host keys with PQC-supported algorithms. Ensure ssh-keygen supports ML-KEM or NTRU Prime hybrid.
Technical Analysis
SSH is NOT quantum safe by default, but PQC support is available. **How SSH Works:** Secure Shell (SSH) is a cryptographic network protocol for secure remote login, command execution, and file transfer. SSH typically uses RSA, ECDSA, or Ed25519 keys for host authentication and user authentication, combined with Diffie-Hellman or ECDH for session key exchange. The negotiated symmetric cipher (AES-256-GCM, ChaCha20-Poly1305) encrypts the actual data transfer. SSH operates in two phases: (1) Key exchange and authentication, where the client verifies the server's host key (RSA/ECDSA/Ed25519) and the server verifies the user's credentials (password or public key), and (2) Encrypted session, where symmetric encryption protects the data channel. Most SSH deployments use ECDH (curve25519-sha256) for key exchange and Ed25519 or ECDSA for authentication. SSH is critical infrastructure: system administrators use SSH for remote server management, automated deployments and CI/CD pipelines rely on SSH for git operations and deployment, cloud infrastructure (AWS, Azure, GCP) uses SSH for instance access, and DevOps tools (Ansible, Puppet, Chef) use SSH for configuration management. **Quantum Vulnerability Explained:** SSH's quantum vulnerability centers on asymmetric cryptography: **Host keys (RSA/ECDSA/Ed25519):** Server authentication relies on host keys signed with algorithms vulnerable to Shor's algorithm. A quantum adversary could impersonate SSH servers by forging host keys, enabling man-in-the-middle attacks. **User authentication keys:** SSH public key authentication uses the same vulnerable algorithms. Quantum adversaries could forge user credentials, gaining unauthorized access to systems. **Key exchange (ECDH/DH):** The session key establishment uses elliptic curve or classical Diffie-Hellman, both Shor-vulnerable. Adversaries harvesting SSH sessions today can decrypt them post-quantum via HNDL attacks. The symmetric layer (AES-256, ChaCha20) is quantum-safe, so the protocol framework is sound — only the asymmetric primitives require replacement. **Migration Path:** OpenSSH has led PQC adoption with hybrid implementations: **OpenSSH 9.0+ (April 2022):** Added sntrup761x25519-sha512 hybrid key exchange by default, combining Streamlined NTRU Prime (post-quantum KEM) with X25519 (classical ECDH). This protects key exchange against quantum attacks while maintaining classical security. **OpenSSH 9.5+ (2024):** Added support for ML-KEM-768 hybrid key exchange, aligning with NIST FIPS 203 standards. Configuration: KexAlgorithms sntrup761x25519-sha512,mlkem768x25519-sha256 **Host key migration:** Plan transition to post-quantum host keys once standardized (ML-DSA or SLH-DSA). Interim: maintain existing Ed25519/ECDSA keys while enabling hybrid key exchange. **User key rotation:** Regenerate user SSH keys with PQC-capable algorithms when available. Current best practice: Ed25519 keys (smallest, fastest classical algorithm) with hybrid key exchange protecting sessions. **Industries at Risk:** Cloud infrastructure providers and DevOps teams managing thousands of servers via SSH face critical HNDL risk. Recorded SSH sessions contain deployment credentials, database passwords, API keys, and intellectual property (source code, configuration files). Financial services use SSH for database administration, trading system management, and inter-server communication in high-frequency trading environments. Captured sessions could expose trading algorithms, customer data, and regulatory compliance information. Government and defense systems rely on SSH for classified network administration, secure communications infrastructure, and weapons systems management. Nation-state adversaries actively harvest SSH traffic for future quantum decryption. Managed hosting and colo providers administering customer infrastructure via SSH expose client systems to HNDL attacks. A breach of captured SSH sessions could compromise multiple customer environments simultaneously. **Timeline:** - **2022**: OpenSSH 9.0 enabled hybrid PQC key exchange by default — the first major protocol to deploy post-quantum protection proactively. - **2024-2025**: OpenSSH 9.5+ supports ML-KEM hybrid modes. Upgrade recommended for systems handling sensitive data. - **2030**: NSA CNSA 2.0 requires PQC-capable SSH for national security systems. Commercial sector migration recommended. - **2035**: Classical-only SSH key exchange expected to be deprecated. PQC host and user keys may be required. Organizations should upgrade to OpenSSH 9.0+ immediately to enable hybrid PQC key exchange and plan host/user key migration to ML-DSA when standardized.
| Full Name | Secure Shell Protocol |
| Category | protocol |
| Quantum Vulnerability | RSA/ECDSA/Ed25519 host keys and user keys are Shor-vulnerable. Key exchange (ECDH) is Shor-vulnerable. |
| NIST Status | NIST recommends PQC transition for SSH. OpenSSH has been ahead of the standard. |
| Deprecation Timeline | Classical SSH key exchange algorithms deprecated by 2030 (NIST IR 8547) |
| Replaced By | SSH with hybrid PQC key exchange (OpenSSH 9.0+) |
Migration Guidance
Upgrade to OpenSSH 9.0+ for hybrid PQC key exchange. Regenerate host keys with PQC-supported algorithms. Ensure ssh-keygen supports ML-KEM or NTRU Prime hybrid.
How Qryptonic Can Help
Don’t Know Where SSH Lives in Your Stack?
Qscout26 discovers every instance of SSH across your infrastructure in 7 days — with zero operational disruption. 72-hour time to first findings.