1. Overview
Secure communication is a critical aspect of system security in general. SSH (Secure Shell) remains a crucial tool in this chain. It ensures that data is encrypted and safe from attackers. In its symmetric form, SSH uses cipher systems like AES, DES, and others to make an encrypted connection. Both the server and client should agree on a common cipher to use. The stronger the cipher, the harder it is to crack.
However, SSH needs regular maintenance to stay on top of security trends. For example, one area to focus on is ciphers, which SSH uses to encrypt data. Weak ciphers can leave a system vulnerable to attacks. Thus, disabling weak SSH ciphers is vital.
In this tutorial, we’ll see how to identify and disable weak SSH ciphers in Ubuntu Linux.
2. Why Disable Weak Ciphers?
The first step is knowing which ciphers are weak. Ciphers aren’t all the same. With age, some become vulnerable to newly discovered exploits.
Generally, older ciphers like DES, 3DES, Blowfish, ARCFOUR, and CAST are considered weak. Newer ciphers like AES, ChaCha20, and AEAD modes are often much stronger.
Weak ciphers generally use keys smaller than 128 bits. As a result, they could easily be broken by modern computing power.
Strong ciphers have some key characteristics for encryption:
- longer key length
- strong mathematical algorithm
- resistance to known attacks
These properties provide a high level of security against modern attack methods.
Disabling weak ciphers offers several advantages:
- enhanced security: removing vulnerable options significantly reduces the attack surface for malicious users
- compliance: many security regulations mandate the use of strong ciphers; thus, disabling weak ones ensures compliance
- improved performance: modern ciphers are often faster and more efficient than their older counterparts
Weak ciphers are outdated and more easily broken. Hackers can exploit them to access a system and its data. So, it’s best to disable weak ciphers in the first place.
3. Identifying Ciphers
Before we can disable weak ciphers, we need to identify the supported and available ciphers on the current system.
3.1. Using the ssh Command
To identify the ciphers currently available on a system, we can use the ssh command:
$ sudo ssh -Q cipher
...
3des-cbc
aes128-cbc
aes256-ctr
[email protected]
[email protected]
...
The -Q or query option, in combination with the cipher value, lists all the ciphers SSH supports on the system.
3.2. Using sshd_config File
Similarly, the sshd_config file usually contains a line that starts with Ciphers:
$ cat /etc/ssh/sshd_config
...
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,aes192-cbc,aes256-cbc
...
These are the current active cipher groups on the system. Here, we can look for known weak ciphers to see if any are enabled.
Notably, we might not see an explicit list of ciphers in the above file. In this case, the default values are the ones listed in the man page:
$ man sshd_config
...
[email protected],
aes128-ctr,aes192-ctr,aes256-ctr,
[email protected],
[email protected]
...
Moreover, sshd_config uses a comma to separate ciphers when using more than one.
3.3. Using nmap Script
Similarly, we can use nmap to see what ciphers the target server offers.
For this purpose, we use the ssh2-enum-algos.nse script:
$ nmap -sV --script=ssh2-enum-algos.nse -p 22 192.168.29.116
...
| encryption_algorithms: (6)
| [email protected]
| aes128-ctr
| aes192-ctr
| aes256-ctr
| [email protected]
| [email protected]
...
Notably, 192.168.29.116 is the target server IP.
3.4. Specifying Ciphers from Command Line
Let’s see if a server uses a weak cipher like Arcfour:
$ ssh -c arcfour [email protected]
Unknown cipher type 'arcfour'
The -c option specifies the cipher to use for the connection. In this case, we got an error that shows the weak cipher isn’t available.
With each new release of OpenSSH, ciphers are consistently updated. However, certain legacy ciphers remain enabled to ensure compatibility with older versions of SSH clients.
4. Disabling Weak Ciphers
Now, let’s get into the steps to disable weak ciphers in SSH. For this, we edit the SSH daemon configuration file (/etc/ssh/sshd_config) on the server. Here, we can specify the ciphers we want to allow.
To begin with, let’s make a backup of the original file:
$ sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
Next, we open the SSH daemon configuration file:
$ sudo nano /etc/ssh/sshd_config
In this file, we look for the line starting with Ciphers. It lists all the enabled ciphers. Here, we replace the default cipher list with a lineup of strong ciphers like aes192-ctr, aes128-ctr, and others:
Ciphers aes256-ctr,aes192-ctr,aes128-ctr,[email protected]
After making the aforementioned changes, we save the sshd_config file. Subsequently, we restart the SSH service to ensure the new configuration takes effect:
$ sudo systemctl restart sshd
Thus, we should avoid using weak ciphers. These have vulnerabilities that allow remote attackers to obtain clear-text data or recover passwords.
5. Managing Compatibility
One concern when disabling weak ciphers is maintaining compatibility with older systems or clients. If we remove all the legacy ciphers, we may run into connectivity issues.
For example, old clients that only support those weak algorithms may not connect with a new SSH server.
Let’s see an example of a compatibility issue arising from a cipher mismatch. Suppose, we’ve got a server with supported ciphers as aes128-ctr, aes192-ctr, aes256-ctr, and aes128-cbc:
$ cat /etc/ssh/sshd_config | grep Ciphers
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc
Now let’s try to connect with this server using the cipher 3des-cbc:
$ ssh [email protected] -c 3des-cbc
Unable to negotiate with 192.168.29.116 port 22: no matching cipher found. Their offer: aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc
Thus, we can’t connect to the server.
Similarly, issues may arise with key exchange methods.
There are some possible solutions to this problem:
- upgrade the legacy systems
- replace the weak ciphers with modern ciphers
If some legacy systems cannot be upgraded, we may restrict their usage to non-critical tasks.
6. Client-Side Considerations
In the above discussion, we’ve so far considered configuring the SSH server daemon (sshd_config). Yet, it’s possible to deny ciphers on the client side for SSH connections.
The server ultimately decides which cipher to use from the ones offered by both sides. Even if we deny weak ciphers on the client, the server can still choose them if they are enabled on its side.
Let’s disable the 3des-cbc cipher on the client side using the SSH client config file (/etc/ssh/ssh_config):
$ cat /etc/ssh/ssh_config | grep Ciphers
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc
We then try to connect to the server with the 3des-cbc cipher from the client side:
$ ssh [email protected] -c 3des-cbc
[email protected]'s password:
...
Eventually, the connection is successful since the given cipher is enabled on the server. Still, some ciphers aren’t going to be tried by default, unless we specify them explicitly.
Notably, OpenSSH disables several weak ciphers like arcfour. These are unusable for an SSH connection:
$ ssh -c arcfour [email protected]
Unknown cipher type 'arcfour'
These ciphers are now incompatible as per the OpenSSH specifications.
7. Conclusion
In this article, we saw how to disable weak ciphers in SSH.
First, we understood what weak ciphers are and why we might need to disable weak ciphers. Then, we tried to identify all available ciphers on a system and check for weak ones. Next, we went through the steps for disabling ciphers that aren’t strong.
Then, we learned how to manage compatibility with systems using weak ciphers.
Also, we noted that disabling weak ciphers on the server side is a very crucial step. This ensures no clients can connect using weak ciphers, regardless of their configuration.
Finally, we saw that the server-side configuration has more priority than the client side.