How to enforce strong SSH key exchange algorithms

Restricting SSH key exchange algorithms keeps remote administration hardened against downgrade attacks and aging cryptography. A small, explicit list of strong KEX values removes weak defaults such as SHA‑1 based Diffie‑Hellman groups and satisfies scanners that flag legacy algorithms during compliance checks.

In OpenSSH, the key exchange phase is controlled by the KexAlgorithms directive in /etc/ssh/sshd_config, which defines both the algorithms a server offers and their preference order. Modern releases ship with robust options such as curve25519-sha256 plus hybrid post‑quantum schemes like sntrup761x25519-sha512@openssh.com, and commands like ssh -Q kex and sshd -T reveal the supported and currently active lists before any hardening takes place.

Enforcing only strong KEX algorithms must balance compatibility against strictness because older clients, embedded appliances, and some libraries may lack support for curve25519, post‑quantum hybrids, or very large Diffie‑Hellman groups. The procedure below assumes a Linux server running a recent OpenSSH with systemd; configuration validation with sshd -t and access to a console or out‑of‑band method remains critical in case a malformed /sshd_config blocks new SSH logins.

Steps to enforce strong key exchange algorithms in SSH:

Open a terminal session on the SSH server with access to sudo or root privileges.
```
$ whoami
user
```

List all key exchange algorithms supported by the installed OpenSSH client and libraries.

$ ssh -Q kex | sort
curve25519-sha256
curve25519-sha256@libssh.org
diffie-hellman-group14-sha1
diffie-hellman-group14-sha256
diffie-hellman-group16-sha512
diffie-hellman-group18-sha512
diffie-hellman-group1-sha1
diffie-hellman-group-exchange-sha1
diffie-hellman-group-exchange-sha256
ecdh-sha2-nistp256
ecdh-sha2-nistp384
ecdh-sha2-nistp521
sntrup761x25519-sha512@openssh.com

ssh -Q kex prints the algorithms available in the local OpenSSH build, which must exist before being referenced by KexAlgorithms.

Display the effective key exchange configuration that the running sshd instance will use.

$ sudo /usr/sbin/sshd -T | grep -i '^kexalgorithms'
kexalgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256

If no kexalgorithms line appears, the daemon is using its built‑in defaults and will adopt any explicit KexAlgorithms directive added to /sshd_config.

Create a timestamped backup of the existing /etc/ssh/sshd_config file before editing.
```
$ sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%Y%m%d-%H%M%S)
```
A backup copy enables recovery over console or rescue access if a new configuration prevents SSH logins.
Open /etc/ssh/sshd_config in a text editor such as nano to change the key exchange settings.
```
$ sudo nano /etc/ssh/sshd_config
```

Add or update a KexAlgorithms directive so that only strong, SHA‑2 or post‑quantum key exchanges are offered.

# Strong KEX set with hybrid post-quantum first (if supported)
KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256

Avoid SHA‑1 based KEX values such as diffie-hellman-group1-sha1 and diffie-hellman-group14-sha1, and ensure every algorithm listed in KexAlgorithms appears in the ssh -Q kex output.

When only removing weak algorithms instead of rewriting the entire list, use a KexAlgorithms line with a leading minus to subtract them from the defaults.
```
# Example: drop legacy SHA-1 based groups from the default list
KexAlgorithms -diffie-hellman-group1-sha1,-diffie-hellman-group-exchange-sha1
```
Subtractive syntax keeps pace with future strong defaults while suppressing known‑weak algorithms that vulnerability scanners report.
Save the configuration file in the chosen editor and return to the shell prompt once the KexAlgorithms directive matches the desired policy.
Validate the modified SSH configuration before restarting the service.
```
$ sudo sshd -t
```
No output from sshd -t indicates syntactically valid configuration and allows a safe service restart.

Related: How to check and validate the SSH server configuration
Restart the SSH service to load the new key exchange settings.
```
$ sudo systemctl restart ssh
```
Restarting ssh replaces the daemon process; if validation was skipped or failed, new SSH connections can break until the configuration is corrected over console access.

Related: How to manage the SSH server service with systemctl in Linux

Confirm that the SSH service is active after the restart.

$ sudo systemctl status ssh
● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/usr/lib/systemd/system/ssh.service; enabled; preset: enabled)
     Active: active (running) since Sat 2026-01-10 12:19:38 +08; 17h ago
TriggeredBy: ● ssh.socket
       Docs: man:sshd(8)
             man:sshd_config(5)
   Main PID: 10704 (sshd)
      Tasks: 1 (limit: 4546)
     Memory: 4.2M (peak: 19.4M)
        CPU: 246ms
     CGroup: /system.slice/ssh.service
             └─10704 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups"
##### snipped #####

From a test client, initiate a verbose SSH connection and confirm that a strong key exchange algorithm is negotiated.

$ ssh -vv host-cipher
OpenSSH_9.6p1 Ubuntu-3ubuntu13.14, OpenSSL 3.0.13 30 Jan 2024
##### snipped #####
debug2: KEX algorithms: sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,ext-info-c,kex-strict-c-v00@openssh.com
##### snipped #####
debug1: kex: algorithm: sntrup761x25519-sha512@openssh.com
##### snipped #####

The kex: algorithm line must show one of the configured strong algorithms so that external audits and vulnerability scans no longer report weak SSH key exchange support.