Securing SSH Connections

Securing SSH Connections

As we learned in the recent NSA leaks, the spy agencies claim to have an attack vector on SSH connections.
This sounds very scary at first. SSH being one of the core protocols to administrate and control our infrastructure, it is of course a pristine target for snooping information and spying on us. And it is definitely possible that the NSA has a 0-day (an undisclosed security flaw), which they are exploiting to look into SSH based communications.
On a second look, we should not panic at this point (or ever). We know too little to say with certainty what is going on exactly and where the spy agencies’ capabilities lie – and they don't say literally they can break all SSH interactions.

Keep Calm and Do Something

For my part I think it is safe to assume that IF they (or some other villain) can attack or decrypt some SSH csonnections, it's much more easy if we misconfigure our servers with old, outdated and insecure crypto ciphers. Maybe these wrong configurations are the only systems they can attack.
Unfortunately, some linux distros out there seem to ship OpenSSH with suboptimal ciphers, key extensions and macs in the default configurations. E.g. CentOS 6.6 does allow 3des-cbc and arcfour128 as a default. Both RC4 and DES can be considered to be broken an though should not be used anymore. There is a lot of talk about compatibility to older clients and such, but I think we shouldn't waste any more time and force old clients to upgrade.
Let's make it much much harder to break into our servers with some "easy" configuration tweaks.

Good encryption, now!

We need to configure our SSH clients and servers in the best known way to support only crypto that is considered strong as of today, that will keep up for the coming years (thinking about super computers and Moore's law) and supports Perfect Forward Secrecy (PFS).

In order to achieve the best SSH security today, you should read stribika's excellent explanation of SSH security configurations. It explains all the sane options and todos for server and client.

For those who want the quick fix on the client side, here are the configuration options you should use at the moment:

Edit your ~/.ssh/config file and add

Afterwards set the file permissions to this:

 chmod 600 ~/.ssh/config

These options disable a lot of insecure modes and force the better ones. Not every SSH server might allow you to connect with this configuration. If any other server you use has a suboptimal configuration (e.g. you can't connect with these client settings) and you are not able to change your server's sshd config (shared hosting), let the provider know about these issues right away! Temporarily you can add extra parameters for old servers (as indicated in the ssh connection error message) above the Host *:

Host    MACs some-other-less-secure-setting-offered-by-your-server

On a side note: these client settings should work with OpenSSH6.6 client and upwards. For those people that use OS X and are still running the default OpenSSH6.2_p2, looke here on how to update your SSH. In the mean time use the following:

The onion way - interleave different layers of security

Jacob Appelbaum mentioned at the 31C3 conference that additional security can be provided by channeling your SSH connections through other protocols like TOR or through a TOR hidden service. This would add another layer of crypto that could prevent an attacker from gaining access to your data. In general, just using multiple encryptions within each other is not by itself a good approach. If you e.g. use the same crypto algorithm twice, it's not adding any more protection. But we know from the NSA that they have a hard time attacking TOR, so Jacob might be just right to advocate this approach – for now.

Show Comments