Recently we came across some Linux systems still supported by Long Term Support (LTS) but running a weak Secure Shell (SSH) server configuration. SSH allows you to log in to a server using a securely encrypted connection. By further digging into this matter, we discovered that this is the default setup for these systems.
We found this weak configuration in several Linux flavours still under LTS, namely Centos 6 (OpenSSH_5.3p1), Ubuntu 14 (OpenSSH_6.6.1) and Debian 8 (OpenSSH_6.7p1). More recent Linux versions include OpenSSH version 7, which has more secure default settings. In this blog we’ll show you how you can harden the older SSH daemons running on these systems so they can still be used securely.
What’s the problem?
No cryptographic method can withstand the test of time. Methods deemed safe could very well be deemed unsafe next year. A lot of cryptographic options offered by the default configuration of SSH servers on LTS systems have proven to be unsafe:
- All KEX algorithmes that use a Diffie-Hellman key smaller than 2048 bits;
- All *-CBC and RC4 ciphersuites;
- All HMAC algorithmns except for
To check which methods are offered by your SSH server, you can use the command
sudo sshd -T.
Running the default configuration introduces a risk. An attacker or malicious user could abuse the weak cryptographic methods and possibly decrypt the connection between you and the server. Several known attacks exist that could be used by an attacker to accomplish this, such as Logjam, FREAK and padding oracles. Logjam is a security vulnerabilty in small Diffie-Hellman key exchanges from 512 to 1024 bit keys. Freak is a similar vulnerability again targeting small keys. A padding oracle is a way for an attacker with the ability to modify ciphertext sent to a server to extract the value of the plaintext.
You can easily harden your SSH server by editing your
sshd_config, normally found in the
/etc/ssh/ folder. Add the following lines to the config to enforce the use of strong cryptographic ciphers:
After adding these lines, restart the SSH daemon and the new configuration should be active. You can verify this by using
sudo sshd -T again. Another way to verify this is by setting up an SSH connection to the server and adding the
-vv flag to enable very verbose output.
It is indeed possible to safely manage older Linux installations under Long Term Support via SSH, but the configuration needs to be tightened up a bit. If this is done according to the method above, the somewhat older version of the SSH server can continue to be used safely.