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?
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.
When an SSH client connects to a server, they exchange lists of parameters including:
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.
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
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.
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.