On 10/03/2021 20:05, Aaron Jones wrote:> On 10/03/2021 15:55, Daniel Pocock wrote: >> Does the command for checking ssh-rsa distinguish between SHA-1 >> (insecure) and SHA-2? > > The older ssh-rsa algorithm *only* uses SHA-1. The SHA-2 versions are > rsa-sha2-256 and rsa-sha2-512. If connecting to a server succeeds when > the former is excluded, the server supports SHA-2. If it does not, it > only supports SHA-1. > > This also has nothing to do with the MACs setting; HMAC-SHA1 is still > secure (as is HMAC-MD5).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: https://access.redhat.com/discussions/3121481 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 ? Is there any SHA1 value cached in known_hosts or does that only contain full public keys? Regards, Daniel
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: > > https://access.redhat.com/discussions/3121481 > > 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 KExAlgorithms curve25519-sha256 MACs umac-128-etm at openssh.com 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: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20210310/aa28aa06/attachment-0001.asc>
Daniel Pocock <daniel at pocock.pro> writes:> 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 ?You may find interest in the IETF draft https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-kex-sha2/ Any KeX with *sha1* in the name should be avoided or put last in the list to be negotiated.> Is there any SHA1 value cached in known_hosts or does that only > contain full public keys?The SSH host keys are just the public keys. The hash is determined by the negotiation. Be safe, stay healthy, -- Mark
As others have mentioned, there is guidance about this in draft-ietf-curdle-ssh-kex-sha2: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-kex-sha2/ In summary, of these SHA-1 KexAlgorithms: * diffie-hellman-group1-sha1 * diffie-hellman-group14-sha1 * diffie-hellman-group-exchange-sha1 and these SHA-1 GSSAPIKexAlgorithms: * gss-gex-sha1- * gss-group1-sha1- * gss-group14-sha1- ?if it is necessary to enable one of them for backward compatibility with clients/servers that support only SHA-1 algorithms, then this is the only one that should be enabled: * diffie-hellman-group14-sha1 (for KexAlgorithms) * gss-group14-sha1- (for GSSAPIKexAlgorithms) ?because of the three, only group14-sha1 is using a 2048-bit MODP group. So if one must be enabled, it is the least-bad one to enable. This reasoning was explained in a previous version of the kex draft: https://tools.ietf.org/id/draft-ietf-curdle-ssh-kex-sha2-11.html Unfortunately, the explanation in the current version of the draft is arguably less clear.