SHA-1 practical recommendations?

Aaron Jones me at
Thu Mar 11 06:37:31 AEDT 2021

On 10/03/2021 19:16, Daniel Pocock wrote:
> Thanks for the fast reply
> This is one of the search results for hardening that suggests tweaking
> MACs, this is the reason I wanted to seek clarification:
> What about KexAlgorithms - should people change this either on client,
> server or both to remove entries like
> diffie-hellman-group-exchange-sha1, and diffie-hellman-group14-sha1 ?

Don't get me wrong; disabling old algorithms that you won't be using is
nearly always a Good Thing. It also keeps out a lot of the SSH
dictionary attack bots (but you should still not be using passwords
anyway). I, for example, run all of my servers with:

Ciphers                     chacha20-poly1305 at
HostKeyAlgorithms           ssh-ed25519-cert-v01 at
KExAlgorithms               curve25519-sha256
MACs                        umac-128-etm at
PubkeyAcceptedAlgorithms    ssh-ed25519,rsa-sha2-512,rsa-sha2-256
RekeyLimit                  128M 1h

You will have to evaluate whether this is a suitable choice for your
deployments, and test them, as is the case with any other piece of software.

> Is there any SHA1 value cached in known_hosts or does that only
> contain full public keys?

The known_hosts file only contains keys. There's a difference between
*key type* and *signature algorithm*. The "ssh-rsa" *key type* can still
be used; i.e. you can still run an SSH server with only an RSA host key,
as long as the server supports a SHA-2 *signature algorithm*. The test
command provided in the 8.5 release notes disables the ssh-rsa
*signature algorithm*.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the openssh-unix-dev mailing list