SSH Server Configuration Best Practices?

Question

I have been tasked with reviewing the settings of an SSH server, I'm currently trying to figure out what are the best practices, and I'm having a bit of trouble finding a good answer. I keep finding a lot of information related to web servers, but I don't know if that fully applies here.

These are the currently enabled settings.

SSH Key Type: ssh-dsa (ssh-rsa seems to be recommended)

SSH Ciphers: AES-128-cbc, AES-192-cbc, AES-256-cbc, AES-128-ctr, AES-192-ctr, AES-256-ctr, Rijndael-cbc

SSH MACs: MD5, SHA1, SHA1 96, SHA2 256, SHA2 256-96, SHA2 512, SHA2 512-96

SSH Key Exchange Algorithms: DH-GROUP1-SHA1, DH-GROUP14-SHA1, DH-GROUP14-SHA2 256, DH-GROUP16-SHA2 512, DH-GROUP-EXCHANGE-SHA2 256, ECDH-SHA2-NISTP256, ECDH-SHA2-NISTP384, ECDH-SHA2-NISTP521

Would anyone be able to perhaps point me in the right direction where I can read up on best pactices and what ciphers, MACs, algorithms should be disabled/enabled?

Answer 1

The defaults for a recent version of openssh are good.

The server's asymmetric key type and client's asymmetric key type are specified in HostKeyAlgorithms and PubkeyAcceptedAlgorithms respectively.

• EdDSA over modern curves (Ed25519) is preferred over ECDSA using NIST P curves, which are preferred over RSA signatures which is preferred over DSA signatures (which are dead).
• I believe NIST P curves are not backdoored and are safe to use in ECDH and ECDSA (provided your implementation is good and your CSPRNG is good). See this answer by Thomas Pornin for reasoning.
• The curves need to be at least 256 bits.
• RSA keys need to have a modulus of at least 2048 bits but 3072 or 4096 are better because strictly speaking 2048 bits provides only about 112 "bits of security" while the recommendation is 128.
• All must use SHA2 and not use SHA1.

So, in order:

1. ssh-ed25519
2. ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nistp521
3. rsa-sha2-512, rsa-sha2-256, [email protected]

Don't use:

1. ssh-rsa (this uses SHA1)
2. ssh-dsa (this also uses SHA1 but also DSA is dead)

The sk- variants are for hardware devices that hold the key and are equivalent. The cert variants are for ssh certificates (not X.509 certificates used for TLS) and are equivalent.

The asymmetric key exchange is specified by KexAlgorithms.

ECDH over modern curves (X25519) is preferred over ECDH with NIST P curves which are preferred over FFDHE. Again the curves need to be at least 256 bits, the FFDHE group needs to be at least 2048 bits though again 3072 or 4096 is preferred. Again everything must use SHA2 and not use SHA1.

So, in order:

1. curve25519-sha256, [email protected]
2. ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521
3. diffie-hellman-group16-sha512, diffie-hellman-group15-sha512
4. diffie-hellman-group14-sha256, diffie-hellman-group-exchange-sha256 (2048 bit) - this is up to you, I think 2048 bits is not broken and the NSA will not bother decrypting my recorded SSH traffic in ten or twenty years, but you can say you want at least 4096 bits and that's ok.

Don't use:

1. diffie-hellman-group14-sha1, diffie-hellman-group-exchange-sha1, diffie-hellman-group-exchange-sha1 - because SHA1
2. diffie-hellman-group-exchange-sha256 (1024 bit) - because group is too small
3. diffie-hellman-group18-sha512, diffie-hellman-group17-sha512 - secure but overkill, slow for no reason

The symmetric ciphers can be newer AEAD or older cipher + separate MAC than need to be combined. The cipher is specified by Ciphers and the MAC, if your cipher is not an AEAD is specified by MACs.

• Almost all AEADs (including GCM and ChaCha) are built on top of CTR.
• AES-GCM is the most popular because it is fast and wasn't encumbered by patents like OCB3.
• ChaPoly is popular as the safest choice because it has more security margin than AES and doesn't require special hardware the way AES-GCM does (AESNI and CLMUL). But because both ends of an ssh connection are very likely to be x86 chips that do have the special hardware, AES-GCM is still the most popular.
• For compatibility, AES-CTR combined with HMAC-SHA2 in EtM is safe (but slower).
• If cipher + MAC is used, "encrypt then MAC" is the better combination but we didn't know that in the 90s so it's not the default.
• If a hash function is used (in HMAC), SHA2 should be used and SHA1 should not be used, even though it is safe in HMAC, because better to just not use SHA1.
• SHA-512 is faster than SHA-256 on 64bit chips (like servers, laptops, smartphones and tablets).

So, in order:

1. [email protected] ciphers
2. [email protected], [email protected] ciphers
3. aes128-ctr, aes192-ctr, aes256-ctr ciphers when combined with [email protected], [email protected] MACs
4. aes128-ctr, aes192-ctr, aes256-ctr ciphers when combined with [email protected] MACs

Don't use:

1. aes128-cbc, aes192-cbc, aes256-cbc ciphers when combined with [email protected], [email protected] MACs. CBC was disabled by default in openssh 6.7, though maybe safe (but slow) because -etm MAC should protect you. But only if you have to.
2. aes128-cbc ciphers with HMAC MAC but a variant without -etm is probably actually dangerous, definitely avoid.
3. hmac-sha2-512, hmac-sha2-256, [email protected] MACs not in -etm variant sound dangerous, avoid.
4. twofish-cbc, twofish128-cbc, twofish256-cbc, twofish128-ctr, twofish256-ctr ciphers - Twofish is a cipher that didn't become popular. It has received much less scrutiny than AES and ChaCha, because it is less popular. It's probably safe, but I would not use it.
5. 3des-cbc, 3des-ctr ciphers - 3DES is slow and has a small 64bit block which makes it susceptible to SWEET32, don't use.
6. arcfour, arcfour128, arcfour256, blowfish, cast ciphers - These are obsolete, don't use them. Arcfour (RC4) is definitely broken.
7. hmac-sha1 MAC - better to just not use SHA1
8. [email protected], [email protected] MACs - small tag size, don't use.

NIST are working on cryptography that is not vulnerable to big quantum computers. They aim to standardize something long before anyone has a big enough quantum computer, so that by the time a big quantum computer is built to decrypt long ago recorded traffic, the information is irrelevant. People are running experimental PQC algorithms. I would wait for this to shake down and switch to whatever emerges.

Answer 2

I think the IETF CURDLE stuff is a good place to start, see this. I hadn't looked at it in a while, but it appears a lot of the stuff has been moved from draft status to RFC. The only one that's not right now is a suggested updated for KEX for SSH.

Answer 3

For me ssh.com is a good reference. If you want specific SSH server best practices it's the place to go to. There's also a section on cryptography policy.

For cryptographic mechanisms to be used in SSH server I would go to BSI TR-02102-4 (01-2021) recommendations.

Answer 4

One thing you might want to do is disable password authentication and enable public key authentication.

As per SSH.com:

The motivation for using public key authentication over simple passwords is security. Public key authentication provides cryptographic strength that even extremely long passwords can not offer. With SSH, public key authentication improves security considerably as it frees the users from remembering complicated passwords (or worse yet, writing them down).

In addition to security public key authentication also offers usability benefits - it allows users to implement single sign-on across the SSH servers they connect to. Public key authentication also allows automated, passwordless login that is a key enabler for the countless secure automation processes that execute within enterprise networks globally.

Source: https://www.ssh.com/academy/ssh/public-key-authentication

Some instructions to disable password authentication: How to disable ssh password login on Linux to increase security.

If you must continue to support password authentication for some reason, then obviously use strong passwords that cannot be guessed easily or succumb to brute force (dictionary) attacks. Use a password manager for your IT needs.

If you can, in order to reduce the attack surface, you could restrict access to port 22 to static, designated IP addresses under your control - for example your own VPN.

Furthermore, you can also use tools like ipban, sshguard, fail2ban etc to defeat brute force attacks against your SSH service. Even if the attacks are doomed to fail, they consume resources for nothing so just ban the offenders automatically.