Keep Your Secure Shell Functional and Secure

I updated my laptop to the latest OpenBSD release, which included OpenSSH version 7.0, and found myself suddenly unable to update web sites hosted at GoDaddy.

What’s wrong?

Not Everyone Keeps Up To Date

The original symptom was something like this, where username@example.com represents my user name and domain hosted at GoDaddy. Here goes an attempted copy:

$ scp Index.html username@example.com:html/
Unable to negotiate with 184.168.238.1: no matching host key type found.
Their offer: ssh-dss

Let’s ask for some details with one -v for verbose:

$ scp Index.html username@example.com:html/
OpenSSH_7.0, LibreSSL 2.2.2
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to example.com [184.168.238.1] port 22.
debug1: Connection established.
debug1: identity file /home/cromwell/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/cromwell/.ssh/id_rsa-cert type -1
debug1: identity file /home/cromwell/.ssh/id_dsa type 2
debug1: key_load_public: No such file or directory
debug1: identity file /home/cromwell/.ssh/id_dsa-cert type -1
debug1: identity file /home/cromwell/.ssh/id_ecdsa type 3
debug1: key_load_public: No such file or directory
debug1: identity file /home/cromwell/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/cromwell/.ssh/id_ed25519 type 4
debug1: key_load_public: No such file or directory
debug1: identity file /home/cromwell/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.0
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1
debug1: match: OpenSSH_5.1 pat OpenSSH_5* compat 0x0c000000
debug1: Authenticating to example.com:22 as 'username'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr umac-64@openssh.com none
debug1: kex: client->server aes128-ctr umac-64@openssh.com none
Unable to negotiate with 184.168.238.1: no matching host key type found.
Their offer: ssh-dss

We could ask for further details with an additional -v or even two, but the more voluminous debugging information isn’t especially helpful. The important thing to realize is that this is a failure to agree on a public key algorithm for host authentication.

Meanwhile, don’t worry about the “No such file or directory” messages. Each is about the following line, a file named *-cert, and it’s just fine and quite typical to not have OpenSSH certificates in place. Unless you have a very large number of users and/or servers, and you’re trying to set up an alternative to Kerberos, OpenSSH certificates aren’t all that useful.

What Should Happen?

When an SSH client connects to a server, they exchange lists of parameters including:

1. Public key algorithms that the server can use to authenticate itself
   to the client,
2. Supported ciphers for encryption,
3. Message authentication codes (or HMACs) to detect traffic modification,
   and
4. Key exchange methods that can be used to generate session keys

There must be at least one mutually supported choice for each parameter.

As explained on the OpenSSH page about interoperability with legacy installations, OpenSSH 7.0 and later disables the DSA or ssh-dss public key algorithm as it has been deemed to be too weak. That leaves an OpenSSH 7.0 client and GoDaddy’s OpenSSH 5.1 server without a mutually supported server authentication method. GoDaddy supports DSA only, OpenSSH 7.0 doesn’t.

Working Around The Problem

The real fix would be for GoDaddy to update their servers, but I have no influence over that. The workaround is to temporarily re-enable a weak algorithm for just the old hosts. You could try to remember to use arcane command-line options, but it would be better to modify your personal ~/.ssh/config or the system-wide /etc/ssh/ssh_config. Add something like the following to the appropriate file. I am setting this up for three domains with old SSH servers:

## GoDaddy only supports the ssh-dss (DSA) public key algorithm
## for host keys.  OpenSSH 7.0 and greater disables it.
Host example1.com example2.com example3.com
    HostkeyAlgorithms ssh-dss

Protect Against CVE-2016-0777 While You’re At It

The OpenSSH client code from 5.4 through 7.1 contained experimental support for roaming, or resuming SSH connections. The corresponding server code was never shipped, but the client code was enabled by default.

If you were tricked into attempting to connect to a hostile SSH server, the client code could leak client memory including private client user keys.

It’s easy to prevent this, add the following to the appropriate SSH client configuration file while you’re making changes:

# CVE-2016-0777 workaround, see:
# http://undeadly.org/cgi?action=article&sid=20160114142733
Host *
    UseRoaming no

This workaround is no longer necessary once you apply a patch removing the experimental roaming code.

Where Should These Workarounds Go?

It’s up to you! But…

In Learning Tree’s Linux server administration course we talk about your choices for configuration changes and their advantages and disadvantages. All will work, but check out the course for guidance on how to make server maintenance easier in the long run.