Best practices for using post-quantum SSH

This document describes best practices for configuring your workstation and Compute Engine virtual machine (VM) instances to use post-quantum key exchange algorithms for SSH connections.

To learn more about how SSH connections work in Compute Engine, see SSH connections to Linux VMs. To learn about managing SSH access with IAM, see About OS Login.

The following sections describe post-quantum cryptography in the context of SSH:

• Understand the threat of capture-now, decrypt-later attacks
• Understand the scope of post-quantum protection in SSH

The following sections contain best practices that can help you protect SSH connections against future quantum computing threats:

• Configure your SSH client to prefer or require post-quantum algorithms
• Configure your VM for post-quantum key exchange
• Verify the negotiated key exchange algorithm

Understand the threat of capture-now, decrypt-later attacks

Classical public-key cryptography (such as RSA and elliptic-curve cryptography) is theoretically vulnerable to attack by quantum computers. Although large-scale quantum computers don't exist yet, adversaries can capture and store encrypted network traffic today with the goal of decrypting it later when a sufficiently capable quantum computer becomes available. This is known as a capture-now, decrypt-later attack.

To protect against this threat, OpenSSH and other modern SSH clients support post-quantum cryptography (PQC) key exchange methods. These methods use hybrid key exchange algorithms that combine a post-quantum algorithm with a classical algorithm (such as X25519). As long as either algorithm remains secure, the session's encryption key cannot be derived by an eavesdropper.

The following hybrid post-quantum key exchange algorithms are supported in modern SSH implementations:

• sntrup761x25519-sha512@openssh.com: A hybrid of Streamlined NTRU Prime 761 and X25519. Supported in OpenSSH 9.0 and later, and PuTTY 0.78 and later.
• mlkem768x25519-sha256: A hybrid of the NIST-standardized ML-KEM-768 (formerly CRYSTALS-Kyber) and X25519. Supported in OpenSSH 10.0 and later, and PuTTY 0.83 and later. mlkem768x25519-sha256 is the current preferred post-quantum key exchange algorithm for SSH.

Understand the scope of post-quantum protection in SSH

An SSH connection involves three cryptographic phases:

1. Key exchange (KexAlgorithms): The client and server establish a shared symmetric secret. When you use a post-quantum key exchange algorithm, this shared secret is protected from decryption by quantum computers.
2. User and host authentication: The client verifies the server host key, and the server verifies the user's SSH key or certificate. Standard OpenSSH doesn't yet use post-quantum signature algorithms for user authentication, but because authentication occurs inside the encrypted channel established by the key exchange, your credentials and host keys are protected from retroactive decryption.
3. Session data encryption (Ciphers): Once keys are exchanged, the session is encrypted using a symmetric cipher (such as aes256-gcm@openssh.com or chacha20-poly1305@openssh.com). Symmetric ciphers aren't vulnerable to quantum computing attacks in the way that asymmetric (key exchange) ciphers are.

How algorithm negotiation works

During the SSH connection handshake, the client sends an ordered list of key exchange algorithms that it supports. The server compares the client's list against its own supported algorithms and selects the first algorithm in the client's list that the server also supports.

Because the client determines the preference order, configuring your workstation client to prefer post-quantum algorithms ensures that post-quantum key exchange is used whenever the target VM supports it.

Configure your SSH client

Configure the SSH client on your workstation to prioritize or enforce post-quantum key exchange algorithms. Complete the steps for your preferred client tool.

Configure your VM

To use post-quantum key exchange algorithms, your VM's operating system and SSH daemon must support them. Review the compatible operating systems and understand the default behavior before making configuration changes.

Compatible operating systems

To support post-quantum key exchange, your VM must run an operating system that includes OpenSSH 9.0 or later. The following public Linux images available on Compute Engine include OpenSSH 9.0 or later:

• Debian: Debian 12 (Bookworm) and later
• Ubuntu: Ubuntu 24.04 LTS (Noble Numbat) and later
• Fedora: Fedora 39 and later
• Container-Optimized OS: Milestone 109 and later
• Rocky Linux / AlmaLinux: Version 10 and later

Older operating system releases (such as Ubuntu 22.04 LTS, Debian 11, or RHEL 9) include OpenSSH versions earlier than 9.0 by default and don't support post-quantum key exchange.

Default behavior

If your VM runs an operating system with OpenSSH 9.0 or later, the OpenSSH server (sshd) supports sntrup761x25519-sha512@openssh.com by default. VMs running OpenSSH 10.0 or later also support mlkem768x25519-sha256 by default.

By default, no changes to the VM configuration are required. When a post-quantum capable client connects, the VM automatically negotiates a post-quantum key exchange. At the same time, the VM continues to accept connections from clients that only support classical algorithms.

Strictly require post-quantum algorithms

If your organization requires post-quantum key exchange for all SSH sessions, you can configure the VM's SSH daemon to accept only post-quantum key exchange algorithms.

To strictly require post-quantum algorithms on your VM:

1. Connect to your VM using SSH.

2. Create a drop-in configuration file in /etc/ssh/sshd_config.d/:

   sudo bash -c 'cat << 'EOF' > /etc/ssh/sshd_config.d/99-post-quantum-kex.conf
   # Require post-quantum key exchange algorithms only
   KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com
   EOF'
   

3. Test the SSH daemon configuration for syntax errors:

   sudo sshd -t
   

   If the command produces errors, check the configuration file before proceeding.

4. Reload the SSH daemon to apply the change without dropping active sessions:

   sudo systemctl reload sshd
   

   If your Linux distribution uses ssh as the service name, run sudo systemctl reload ssh instead.

5. Keep your current terminal window open, and open a new terminal window to test connecting to the VM. If the new connection succeeds, your VM is successfully configured to require post-quantum algorithms.

Recover from an SSH lockout

If you configure your VM to strictly require post-quantum algorithms and get locked out because your client doesn't support the required algorithms, use one of the following recovery options:

1. Use SSH-in-browser: Open the Cloud de Confiance console and connect using SSH-in-browser. SSH-in-browser supports post-quantum key exchange and can connect even when post-quantum algorithms are strictly required on the VM. Once connected, remove or modify /etc/ssh/sshd_config.d/99-post-quantum-kex.conf and reload sshd.
2. Use the virtual serial console: Connect to the VM using the special administrative console (SAC) or serial console. Log in with your credentials, remove the configuration file, and reload sshd.
3. Use a startup script: If interactive access is unavailable:
   1. In the Cloud de Confiance console, stop the VM.
   2. Edit the VM metadata to add a startup script deleting the /etc/ssh/sshd_config.d/99-post-quantum-kex.conf configuration file you previously created, then restarting the SSH server daemon: startup-script: rm -f /etc/ssh/sshd_config.d/99-post-quantum-kex.conf && (systemctl reload ssh || systemctl reload sshd)
   3. Start the VM. The startup script runs as root and restores classical compatibility.
   4. Remove the startup script from metadata after you regain access.

Verify the negotiated key exchange algorithm

To confirm that an active SSH connection is using a post-quantum key exchange algorithm, check the connection details from your client.

Verify using OpenSSH or gcloud CLI

Connect to your VM with verbose output enabled by using the -v flag:

• Using OpenSSH:

  ssh -v -i <var>PATH_TO_PRIVATE_KEY</var> <var>USERNAME</var>@<var>EXTERNAL_IP</var>
  

• Using gcloud CLI:

  gcloud compute ssh <var>VM_NAME</var> --zone=<var>ZONE</var> -- -v
  

Inspect the terminal output during connection establishment. Look for the kex: algorithm line:

debug1: kex: algorithm: sntrup761x25519-sha512@openssh.com

or:

debug1: kex: algorithm: mlkem768x25519-sha256

If the output lists sntrup761x25519-sha512 or mlkem768x25519-sha256, the connection is protected by post-quantum key exchange. If it lists an algorithm like curve25519-sha256 or ecdh-sha2-nistp256, the connection is using classical key exchange and is still vulnerable to "capture now, decrypt later" attacks.

Verify using PuTTY

1. In PuTTY, connect to your VM.
2. Right-click the PuTTY window title bar and select Event Log.
3. In the PuTTY Event Log window, look for the line indicating the key exchange algorithm:
   • Using NTRU Prime / Curve25519 hybrid key exchange
   • Using ML-KEM / Curve25519 hybrid key exchange

What's next

• Learn more about SSH connections to Linux VMs.
• Review Best practices for securing SSH access.
• Learn how to Protect SSH credentials with security keys.
• Learn about SSH-in-browser features and configuration.