SHA-1 practical recommendations?
me at aaronmdjones.net
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 openssh.com
HostKeyAlgorithms ssh-ed25519-cert-v01 at openssh.com
MACs umac-128-etm at openssh.com
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the openssh-unix-dev