Using Custom Ciphers

There is no doubt SSH is an awesome piece of software. It is used by zillions of users, sysadmins and engineers all over the world. Nonetheless it has to constantly keep up with the new threats, bugs and weak points that are pointed out every year.

This makes this software to evolve quite rapidly. In just one year you might find out that some algorithms that were considered secure up until some point in time, have been deprecated and some new ones have replaced them. Fortunately there's always some common denominator even between quite distant versions, that allows us to exchange commands and data between quite heterogeneous systems.

In any case as one of my favourite songs states: "There's always a price to pay", and the price for highly secure communications is CPU cycles. This CPU load generally causes some noticeable decrease in speed, which in the end makes our backups take longer than desired.

The algorithm used to encrypt data over SSH plays an crucial role in how much we load the CPU and also the effective speed we achieve. Thus the ability to choose the cipher to employ in the SSH tunnel is an option that we have recently introduced in XSIBackup-Pro via the --ssh-ciphers argument.

We had previously added the Less Secure Ciphers option, which was a way to allow users to simply turn on some deprecated algorithms through the :l flag in the --backup-prog argument, that would in turn allow the effective throughput to increase considerably.

There's an algorithm which is quite secure and produces at the same time a very small footprint on the CPU, that is: chacha20-poly1305@openssh.com. On addition, of course, you may also try to use some Less Secure Ciphers if you can afford to.

We have made some attempts since version 11.2.4 to choose some convenient ciphers automatically, but due to the growing number of OpenSSH versions and possible combinations, we have decided to just offer three options in regards to the use of ciphers:

1 - OpenSSH default negotiation: let OpenSSH on both ends decide which cipher to use depending on the ones configured by default.
2 - Less Secure Ciphers: use a flag to turn this feature on. It might not work by just turning the feature on, as your OpenSSH server might not allow to use it. It may require you to add the cipher (in case it's possible) to the /etc/ssh/sshd_config file.
3 - User Custom Ciphers: use the --ssh-ciphers argument to set your list of preferred ciphers. As in the previous option, you might need to delve a bit into your OpenSSH version to find out what ciphers are built in and evetually turn them on by editing the /etc/ssh/sshd_config file.

How to use custom ciphers

OpenSSH documentation is sometimes not easy to interpret. Configuring ciphers can be a bit cumbersome at the beginning, but we will try to explain here how to deal with this task as simply as possible.

OpenSSH has two main components, namely: the OpenSSH client and the OpenSSH server. There is a way in newer versions to get a list of the client supported ciphers by issuing the command:

ssh -Q cipher

In older versions (7.5 and below) the way to find out which ciphers are supported is more complicated. You may read this post at superuser.com to have a quick idea of what methods are available.

The above is a client command so that list is supposed to be the list of ciphers supported by the client. You can nevertheless make the assumption that the counterpart server (same version), will support the same list.

That does not mean that you can just choose a cipher from that list and use it to connect to a server by the same version as the connecting client. You must explicitly enable that cipher in the /etc/ssh/sshd_config file by prepending it to the list of ciphers in the Ciphers variable.

You may add something like this to that file:

Ciphers chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,3des-cbc

The above line will enable the chacha20-poly1305@openssh.com cipher and give it maximum preference, as they are negotiated in order. You must, of course, first make sure that the cipher is supported by the server, or you will receive the corresponding error. The best part is that you don't need to restart the service for the new values to be enabled. You can apply the same methodology for any cipher, including Less Secure Ciphers

Daniel J. García Fidalgo
33HOPS