Securing SSH Server Configuration in 2025

This is an update to my 2020 article on securing sshd configuration. A lot has changed since then. OpenSSH picked up post-quantum key exchange (we’ve all seen those annoying warnings), strictended its defaults, and dropped a handful of algorithms that are not relevant anymore.

What’s changed since 2020

#

A few notable things have happened: OpenSSH 8.8 deprecated the ssh-rsa host key algorithm because its SHA-1 signatures are vulnerable to chosen-prefix collisions. OpenSSH 9.0 introduced post-quantum hybrid key exchange with sntrup761x25519-sha512, and 10.0 made ML-KEM-768 (mlkem768x25519-sha256) the default. The Terrapin attack (CVE-2023-48795) led to the kex-strict extension in late 2023.

These settings apply to modern OpenSSH across all platforms. The paths and commands shown here may be FreeBSD-specific, but you can use these on any host that runs openssh server.

Auditing your SSH server

#

Before making changes, audit your current configuration. I’ve updated SSHScan to version 2.0 with a refreshed algorithm security database. It now flags both broken and questionable algorithms, and recognizes the post-quantum KEX names.

Here’s a scan of a modern OpenSSH 10.0 server:

% ./sshscan.py sdf.org

[*] Initiating scan for sdf.org on port 22
[*] Connected to sdf.org on port 22...
    [+] Target SSH version is: SSH-2.0-OpenSSH_10.0
    [+] Retrieving algorithm information...
    [+] Detected ciphers:
          chacha20-poly1305@openssh.com        aes128-ctr
          aes128-gcm@openssh.com               aes192-ctr
          aes256-gcm@openssh.com               aes256-ctr
    [+] Detected KEX algorithms:
          mlkem768x25519-sha256                ecdh-sha2-nistp256
          sntrup761x25519-sha512               ecdh-sha2-nistp384
          sntrup761x25519-sha512@openssh.com   ecdh-sha2-nistp521
          curve25519-sha256                    ext-info-s
          curve25519-sha256@libssh.org         kex-strict-s-v00@openssh.com
    [+] Detected MACs:
          umac-64-etm@openssh.com              umac-64@openssh.com
          umac-128-etm@openssh.com             umac-128@openssh.com
          hmac-sha2-256-etm@openssh.com        hmac-sha2-256
          hmac-sha2-512-etm@openssh.com        hmac-sha2-512
          hmac-sha1-etm@openssh.com            hmac-sha1
    [+] Detected HostKey algorithms:
          rsa-sha2-512                         ssh-ed25519
          rsa-sha2-256
    [-] No not recommended ciphers detected!
    [+] Detected not recommended KEX algorithms:
          ecdh-sha2-nistp256                   ecdh-sha2-nistp521
          ecdh-sha2-nistp384
    [+] Detected not recommended MACs:
          umac-64-etm@openssh.com              umac-64@openssh.com
          hmac-sha1-etm@openssh.com            hmac-sha1
    [-] No not recommended HostKey algorithms detected!
    [+] Compression is enabled

Algorithm selection rationale

#

SSHScan 2.0 ships with an algorithm security reference that explains the reasoning behind each classification. Where possible, the reasoning cites the original papers, the relevant IETF RFCs, or OpenSSH’s documentation.

Compared to the 2020 list: ssh-rsa host keys are out, since SHA-1 fell to the SHAttered attack. HMAC-SHA1 and UMAC-64 are also out, the first because its cryptographic margins are shrinking, the second because it runs out of birthday security too quickly. Anything Diffie-Hellman based on SHA-1 goes with them.

On the other side, the post-quantum hybrid KEX algorithms (mlkem768x25519-sha256 and sntrup761x25519-sha512) are now what you should be reaching for. Ed25519 stays the host key of choice, RSA is fine if you use rsa-sha2-256 or rsa-sha2-512 for signatures, and Encrypt-then-MAC variants are preferred over the older MAC-then-Encrypt.

The NIST P-curves (ecdh-sha2-nistp256/384/521) are the ones that you should be careful about. They aren’t broken, but the curve generation process has never quite shaken off the suspicion that hung over Dual_EC_DRBG. SSHScan flags them as not recommended for that reason, but if you think I am nitpicking, feel free to ignore those warnings.

Updated configuration

#

Here’s my current recommended /etc/ssh/sshd_config hardening for modern OpenSSH:

## Hardening
UseDNS no
VersionAddendum none
PasswordAuthentication no
PermitRootLogin prohibit-password
LogLevel VERBOSE
AuthenticationMethods publickey

# Enhanced logging for sftp sessions
Subsystem sftp /usr/libexec/sftp-server -f AUTHPRIV -l INFO

# Post-quantum and modern algorithms only
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512

MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com

After modifying the configuration, validate it with sshd -T and reload the service:

# service sshd reload

Then audit again using SSHScan to confirm no insecure or not recommended algorithms remain.

Current best practices

#

Ed25519 is still the host key I’d prefer and recommend because of it’s mathematically strong , but if you have a good reason to use RSA, keep it at 3072 bits or above, and stick to rsa-sha2-256 or rsa-sha2-512 for signatures.

I cannot think if a good reason anyone should use DSA, due to its limited key size (1024-bit keys). You may also considering completely avoiding ECDSA on NIST curves, if you have trust concerns about the curve generation process.

Include the post-quantum hybrid KEX algorithms, even if you don’t think of quantum computing as a near-term threat. It will spare you from those annoying warnings.

The complete algorithm security reference with cryptographic rationales and academic citations is available in the SSHScan repository.