OpenSSH Triple 7 Bug -- a good chance to upgrade your keys

OpenSSH is a very common used tool in server administration and secure data transfer between servers and/or clients. It's deployed on a wide range of servers, clients, routers, mobile phones and possibly even on your DVD player. Unfortunately it's a software which is having bugs, too. This is about the Triple 7 bug, why you should generate new SSH-keys and how to do this.

Triple 7

A few weeks ago version 7.1p2 of OpenSSH has been released which fixed a serious issue that might have a huge effect on security of your SSH keypair. The problem has been registered CVE-2016-0777 and is due to the registration number just called "triple 7".

This is the very short summary of what happened: With version 5.4 -- released back in March 2010 -- OpenSSH introduced a feature to resume old connections, called roaming.

The experimental code was only added to the client side, but activated by default configuration. Unfortunately the code introduced a remote exploitable bug which could be used by a manipulated SSH-server to get knowledge of your private key. As you don't know which server might have been manipulated, assume your keys have been copied if you have used a version between >=5.4 and <= 7.1p1 and connected to some foreign server.

Securing your OpenSSH

The first and most important step is to update OpenSSH to the latest release. Do it. Now. If you are not sure, whether you are affected, check your SSH by calling it with option -V. If you output looks like the example below, you are currently not affected by the bug (but you might have been in the past)

$ ssh -V
OpenSSH_7.1p2, OpenSSL 1.0.2e 3 Dec 2015

Most Linux-distributions are already shipping updated versions. For Other platforms you can download packages from openssh.org. MacOS users can update via e.g. homebrew.

Same old, same old

If you still have to use an OpenSSH-version between >=5.4 and <= 7.1p there are two ways to disable the "feature".  The best way to do so is to deactivate it globally. Add

UseRoaming no

to either your user and/or system-wide configuration file. On most Unix-like-systems this should be /etc/ssh/ssh.conf for system-wide and ~/.ssh/config for your user's configuration. We have deactivated roaming with our 2016_002 release.

You can also deactivate the feature on single connection based by calling SSH with -oUseRoaming=no from command line.

Creating a new keypair

Even if you are not affected by the bug, you should consider updating your SSH keys on a regular basis. Over time some issues on current cryptographic algorithms are detected and new standards published. As an example there have been found many weaknesses on DSA that are decreasing affords to calculate a DSA based private key, so that DSA cannot be considered safe anymore. Since DSA is used to create ssh-dss keys, OpenSSH disabled the usage of ssh-dss keys by default with their 7.0p1 release -- we made this change with our 2015-056 release too -- and may disable short RSA keys with less than 1024 bits in the future because of similar reasons. As the capabilities to calculate RSA are getting better and better, this is a plain step.

Due to the fact we currently recommend to use ECDSA or even better ED25519 based keys. Recent versions of SSH-clients and servers should support both of them (You have updated your installation, right?)

Find out deprecated keys

You should look for DSA-based keys you are still using. In most cases you can find them inside your ~/.ssh-folder (Linux, unix-like). Files are called id_dsa(.pub).

A DSA keypair can be easily identified. The private key look similar to this example:

-----BEGIN DSA PRIVATE KEY-----
MIIBvAIBAAKBgQDHv95Mywrxfrjw320toJq5VC58UWdLIIFlrConz6ACFQ4VC0bW
NyeFlvgncJDWPoJQi/0UIQlDswawRZGPCNHxKI08Q+/WK3Irm6FAgg7kGH6n4uNE
...
LUTRjujGSg4MIeqU02G0Fg==
-----END DSA PRIVATE KEY-----

</pre>
Whereas the public part is structured like this:
ssh-dss AAAAB3N1N.....Lks8s6jZ2cqc5HtWY9TlA1Q3FqNjuu user@some-client
If you are a user of our platform and you were using a ssh-dss key to login to your VM you should have received an email asking you to update your key.

Linux and other Unix-like systems (e.g. MacOS X)

The fastest way is to use the command line / terminal for doing this. To create an ED25519 curve based key run:
$ ssh-keygen -t ed25519 -o -a 100
To generate an ECDSA-key you can use

$ ssh-keygen -t ecdsa

If you really need to use RSA to connect to systems with an old SSH running, ensure you use a long key. This will need some more CPU-resources but this might keeps you save a little longer. A good length is 4096bit here. Even longer keys are better, but not all versions are supporting very long RSA keys. You can do it with
$ ssh-keygen -b 4096

Windows

For Windows there are many different clients available. The most popular one is PuTTY. At PuTTY you can use PuTTYgen to generate a new keypair. We have put some notes and screenshots how to do this into our documentation.
Use a passphrase to secure your private key

A SSH-keypair consists of two components: A public key -- you can copy and give it to everybody you like to -- and a private key. The private key needs to be kept save as this is the part you are using to encrypt/decrypt your secure data or you are using to authorize against a server. We recommend to use of a strong passphrase to save your private key.