This is an update to my 2020 article on securing sshd configuration. Since then, OpenSSH has evolved significantly with the introduction of post-quantum key exchange algorithms and stricter security defaults. Additionally, several previously acceptable algorithms have been deprecated due to recent developments in cryptography.
What’s Changed Since 2020 #
OpenSSH has made important security improvements. Version 8.8 deprecated the ssh-rsa host key algorithm (which uses SHA-1 signatures vulnerable to chosen-prefix collisions). OpenSSH 9.0 introduced post-quantum hybrid key exchange with sntrup761x25519-sha512, and version 10.0 added ML-KEM-768 (mlkem768x25519-sha256) as 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 the configuration principles apply universally.
Auditing Your SSH Server #
Before making changes, you should audit your current configuration. I’ve updated SSHScan to version 2.0 with a more up-to-date algorithm security database based on peer-reviewed cryptographic research. The tool now properly identifies insecure and not recommended algorithms according to current standards.
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
The tool now identifies post-quantum KEX algorithms and properly flags insecure and not recommended options like HMAC-SHA1 and 64-bit UMAC variants.
Algorithm Selection Rationale #
SSHScan 2.0 includes an algorithm security reference documenting which algorithms are considered secure or insecure. Each classification is supported by peer-reviewed research from the cryptographers who designed these algorithms, IETF RFCs, and OpenSSH protocol documentation.
The key changes from 2020 recommendations:
Now deprecated: ssh-rsa host keys (SHA-1 signatures are vulnerable per the SHAttered attack), HMAC-SHA1 variants (reduced cryptographic margins), UMAC-64 (insufficient birthday security), and any Diffie-Hellman variants using SHA-1.
Now recommended: Post-quantum hybrid KEX algorithms (mlkem768x25519-sha256, sntrup761x25519-sha512), Ed25519 for host keys, RSA with SHA-2 signatures (rsa-sha2-256 or rsa-sha2-512), and Encrypt-then-MAC variants for message authentication.
Still debated: NIST P-curves (ecdh-sha2-nistp256/384/521) remain cryptographically sound but carry concerns about potential backdoors due to NIST’s involvement in their standardization. SSHScan flags these as not recommended, though they haven’t been cryptographically broken.
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
Note the removal of ECDSA algorithms and anything using SHA-1. The configuration prioritizes post-quantum hybrid KEX for future-proofing against quantum computing advances.
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 #
For host keys, Ed25519 remains the best choice due to its mathematical strength, side-channel resistance, and performance. If you must use RSA, ensure keys are at least 3072 bits and always use rsa-sha2-256 or rsa-sha2-512 signature algorithms, never ssh-rsa.
Avoid DSA entirely (limited to 1024-bit keys). Avoid ECDSA on NIST curves if you have trust concerns about the curve generation process.
For forward compatibility, include post-quantum hybrid KEX algorithms. While quantum computers capable of breaking classical cryptography don’t exist yet, the hybrid approach provides security even if either component is compromised.
The complete algorithm security reference with cryptographic rationales and academic citations is available in the SSHScan repository.