Recently, you may have encountered error messages connecting to various hosts using SSH although there weren’t any problems with them just a few weeks/months ago. This happens especially with OpenSSH clients starting with version 7.0 and above. This is what a typical error message often looks like:
Unable to negotiate with $1: no matching host key type found.
Their offer: ssh-dss
$1is the IP address of the host you are trying to connect to)
Why does this happen?
The reason behind this is that OpenSSH recently disabled DSS keys by default. This is an excerpt from the relevant part of the release notes for OpenSSH 7.0:
Support for ssh-dss, ssh-dss-cert-* host and user keys is disabled
by default at run-time. These may be re-enabled using the
instructions at http://www.openssh.com/legacy.html
This was done because of the inherent weakness of DSS keys and is expected to happen in future with every algorithm that gets compromised. If you rely on such key types at some point, you will have to take corrective action if you do not want to risk being locked out.
A short note on DSS and DSA
“DSS is simply a document that describes the signing procedure and specifies certain standards. The original document is FIPS 186 and latest revision in 2013 is FIPS 186-4[…] When SSH says DSS, they mean that they’re implementing DSA in compliance with the DSS.”
Source: Adi’s answer about DSS on Information Security Stack Exchange
Since I am only talking about SSH here, I will use both abbreviations where appropriate.
The best thing you can do is to generate new keys using stronger algorithms. For the moment, RSA keys should provide you the largest compatibility with other clients and servers, but there are even more secure algorithms (e.g. ed25519). The thing is that they require recent versions of OpenSSH or similar software on both the client and the server.
However, sometimes you are stuck with DSA keys. For instance, many people use shared hosting and do not have full control over the target server, so they rely on their system administrator taking appropriate action and actually not enforcing the usage of such weak algorithms server-side anymore. Another case is when you are this server administrator and your users haven’t updated their keys yet, so you are forced to let it go for some time until they finally do that. Please note that OpenSSH will drop support for DSA keys entirely, so the text below represents only a temporary solution.
As already quoted from the release notes, there is more information on legacy support in OpenSSH on their website, but to save you some reading, here is what you can do. You can still re-enable DSS support locally by updating your sshd_config and ~/.ssh/config files with lines like
If you have absolutely no idea how to configure your SSH client altogether, here is a working configuration for a specific host:
In order to use it, just change
$somewhere with a reasonably descriptive string of your liking,
$someone with your username remotely on the server, and
$address with the domain name, or IP address, of the server you are trying to connect to. Then you can proceed to add the PreferredAuthentications method below, e.g. either password or publickey with the appropriate IdentityFile, if you choose the latter.
Now you can connect to the target server by issuing
ssh $somewhere in a terminal, or use it for filesystem paths with different command-line tools. Two examples below:
$ scp a.txt $somewhere:Documents/b.txt
$ git clone $somewhere:repos/secret-project.git
Note that you do not actually need to start anything above with
$. This symbol specifies that the word right after it should be substituted with your own data, so that everything works.