Secure Shell or SSH is probably the main mechanism you use daily to administer critical servers. This makes the SSH service a prime target for hackers. It’s present on all your crown jewels and, once broken, it may spill the keys to your kingdom. This article is the first in a series to address important considerations for hardening SSH.
In hardening SSH, we’ll be dealing with a number of specific problem areas:
- Cryptography and key exchange
- Traffic analysis attacks
SSH key exchange
When it comes to cryptography, you deal with keys and ciphers. When setting up a connection using SSH, the first thing both partners exchange is keys. To do this securely you have essentially two options for algorithms: Diffie-Hellman and Elliptic Curve Diffie-Hellman. Both prevent eavesdroppers from storing your encrypted traffic and decrypting it later. This property is called forward secrecy. The end result of a key exchange is that both parties know the same big secret number while any passive listeners will be none the wiser. I’ll skip the mathematics here, but both algorithms depend on the discrete logarithm problem being hard.
Elliptic Curve or not
Algorithms using elliptic curve cryptography (ECC) work faster than those that don’t. At the same time ECC offers equivalent security. Whether you trust ECC depends mainly on the threat quantum computers pose to asymmetrical cryptography. Traditional algorithms seem likely to take a more complex quantum computer to break. The exact impact of the quantum-threat on asymmetrical cryptography remains uncertain for now.
A second reason to opt out of ECC cryptography has to do with trust. The algorithms depend on certain “magic” numbers that were pre-calculated by experts. The level of trust in these magic numbers varies greatly across the community of professional cryptographers. Mainly because the US government’s standard numbers were provided by an NSA employee who failed to explain them sufficiently. Fortunately, alternatives are available.
Assuming you don’t trust NIST or the NSA but you do trust ECC itself, these are the algorithms you can safely use:
Supporting all of them is redundant. It’s fine to only activate curve25519-sha256 but be prepared for issues with compatibility. Not all clients know how to deal with this. For those cases, or if you don’t like ECC, use diffie-hellman-group-exchange-sha256. Add the following line to your sshd_config file to support both:
On your client add the following to ssh_config:
Host * KexAlgorithms email@example.com,diffie-hellman-group-exchange-sha256
If you chose to enable diffie-hellman-group-exchange-sha256, make sure you get rid of all primes smaller than 2047 bits in /etc/ssh/moduli. Also make sure your servers and clients use the same moduli file. If SSH can’t find matching primes between client and server, the exchange will fail.