SHA-1 practical recommendations?

Daniel Pocock daniel at pocock.pro
Thu Mar 11 02:55:11 AEDT 2021


The release notes currently:
- explain the flaws with SHA-1,
- alert people to the evolution of UpdateHostKeys (default since 8.5),
- a command to check if a server uses ssh-rsa
- suggest upgrading OpenSSH

There are a few issues:

What does "default" mean, "yes", or "ask"?  I think it is "yes" but it
could be helpful to clarify that in both release notes and the man page.

Does the command for checking ssh-rsa distinguish between SHA-1
(insecure) and SHA-2?

Many people won't upgrade SSH, they will probably just wait either (a)
they upgrade their whole distribution or (b) their distribution provides
a security update of the package with SHA1 disabled at compile time

Some pages have appeared about tweaking /etc/ssh/sshd_config on every
host, adding the MACs parameter and specifying the secure MACs.  The
OpenSSH release notes don't mention this.

Are there any more specific documents available?

If yes, could you link to them from the release notes and man page?

If no, is there a good place to maintain a FAQ about this issue?

Some of the questions that come to mind from the perspective of somebody
who uses ssh but doesn't look under the hood:

- brief example of how an attack may work in practice

- are hash values cached anywhere in the client (known_hosts), server
(sshd_host*) or only generated on the fly and used on the wire?

- some sites suggest setting MACs in sshd_config, listing only the
secure values, is there a compelling reason to do this proactively?  It
appears more important to set this on the client side

- is there a convenient shortcut to enable only strong hashes in
ssh(d)_config MACs without itemizing them?

- instead of waiting for new versions of the packages to remove SHA-1,
should security-conscious users consider setting MACs in every
sshd_config and ssh_config on their site?



More information about the openssh-unix-dev mailing list