OpenSSH implements all of the cryptographic algorithms needed for compatibility with standards-compliant SSH implementations, but since some of the older algorithms have been found to be weak, not all of them are enabled by default. This page describes what to do when OpenSSH refuses to connect with an implementation that only supports legacy algorithms.
When an SSH client connects to a server, each side offers lists of connection parameters to the other. These are, with the corresponding ssh_config keyword:
KexAlgorithms: the key exchange methods that are used to generate
per-connection keys
HostkeyAlgorithms: the public key algorithms accepted for an SSH
server to authenticate itself to an SSH client
Ciphers: the ciphers to encrypt the connection
MACs: the message authentication codes used to detect traffic
modification
For a successful connection, there must be at least one mutually-supported choice for each parameter.
If the client and server are unable to agree on a mutual set of parameters then the connection will fail. OpenSSH (7.0 and greater) will produce an error message like this:
Unable to negotiate with legacyhost: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1
In this case, the client and server were unable to agree on the key
exchange algorithm. The server offered only a single method
diffie-hellman-group1-sha1. OpenSSH supports this method,
but does not enable it by default because it is weak and within theoretical
range of the so-called Logjam attack.
Several related options come into play later during user authentication.
PubkeyAcceptedKeyTypes (ssh/sshd): the public key
algorithms that will be attempted by the client, and accepted by the server
for public-key authentication (e.g. via .ssh/authorized_keys)
HostbasedKeyTypes (ssh) and HostbasedAcceptedKeyTypes (sshd): the key types that will be attempted by the client, and accepted by
the server for host-based authentication (.e.g. via .rhosts or
.shosts)
A mismatch between the client and server during authentication will cause
authentication to fail, despite it appearing to be configured. For example,
an ssh-dss user key may be listed in
.ssh/authorized_keys but may not pass authentication because,
by default, sshd does not accept this key type.
The best resolution for these failures is to upgrade the software at the other end and/or replace the weak key types with safer modern types. OpenSSH only disables algorithms that we actively recommend against using because they are known to be weak. This might not be immediately possible in some cases, so you may need to temporarily re-enable the weak algorithms to retain access.
For the case of the above error message, OpenSSH can be configured to enable
the diffie-hellman-group1-sha1
key exchange algorithm (or any other that is disabled by default) using
the KexAlgorithms option, either on the command line:
ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 user@legacyhost
or in the ~/.ssh/config file:
Host somehost.example.org KexAlgorithms +diffie-hellman-group1-sha1
The '+' before the list instructs ssh to append the algorithm to the client's default set rather than replacing the default. By appending, you will automatically upgrade to the best supported algorithm when the server starts supporting it.
Another example, this time where the client and server fail to agree on a public key algorithm for host authentication:
Unable to negotiate with legacyhost: no matching host key type found. Their offer: ssh-dss
OpenSSH 7.0 and greater similarly disable the ssh-dss (DSA)
public key algorithm. It too is weak and we recommend against its use.
It can be re-enabled using the HostKeyAlgorithms configuration
option:
ssh -oHostKeyAlgorithms=+ssh-dss user@legacyhost
or in the ~/.ssh/config file:
Host somehost.example.org HostKeyAlgorithms +ssh-dss
Depending on the server configuration, it's possible for other connection
parameters to fail to negotiate. You might find the Ciphers and/or
MACs configuration options useful for enabling these. It's
also possible to query which algorithms ssh supports:
ssh -Q cipher # List supported ciphers ssh -Q mac # List supported MACs ssh -Q key # List supported public key types ssh -Q kex # List supported key exchange algorithms
Finally, it's also possible to query the configuration that ssh is actually
using when attempting to connect to a specific host, by using the -G
option:
ssh -G [email protected]
which will list all the configuration options, including the chosen values for
the Ciphers, MACs, HostKeyAlgorithms and
KexAlgorithms parameters.