SSH uses a hash algorithm in couple of places:
- As a pseudo-random function in the key exchange (e.g., with
diffie-hellman-group14-sha1).
- As a message authentication code (e.g.,
hmac-sha1)
- To sign a signature over the negotiated session hash to authenticate both parties (e.g., with
ssh-rsa)
- To sign certificates if you're using OpenSSH certificates (e.g., with
[email protected])
Uses 1 and 2 are still secure, since they rely on properties of the hash function that don't involve collision resistance, which is what's weak about SHA-1 (although there are uses of HMAC-SHA-1, such as commitment schemes, where collision resistance is required). Therefore, there's no reason that SHA-1 itself is weak here.
Use 3 is more questionable, since you're performing a signature, where collision resistance is required, although this is probably not practically attackable. The attacker would have to have some way of guessing the shared Diffie-Hellman secret or a derived value, and we generally expect that to be computationally infeasible. That's because SHA-1 is weak to collision attacks, so an attacker has to be able to produce two messages (which, with current attacks, are of a certain form) that hash to the same value, and it would be hard to do that in an online manner without the assistance of the server.
Use 4 is a serious problem. Because we assume users can generate their own key pairs, using SHA-1 to sign a certificate is very weak. OpenSSH certificates contain somewhat less data than X.509 certificates and exploiting this is therefore likely to be more difficult, but this is the threat I would worry about most, and it's the one that the OpenSSH developers are most worried about as well. If an attacker carried out an attack here, the attacker could get access to systems they should not due to an invalid certificate being accepted when it should not be.
So if you're not using OpenSSH certificates, you're probably not at a direct risk from attack. However, there are more reasons to avoid using SHA-1 if you can:
- It's weak in many practical cases and we prefer to use cryptographic primitives which are unambiguously strong.
- We don't want to encourage others to use SHA-1 at all, since even if we're using it in a secure way, others might decide to use it as well and then use it in an insecure way.
- It sets off security scanners and causes compliance problems, as you've noticed.
It goes without saying that all of these also apply to MD5, which you should definitely not use. And there are some additional reasons why SHA-1-based algorithms are bad in SSH particularly:
- Most of the SHA-1-based key exchange algorithms use groups that provide less than 128 bits of security. Because the security of the key exchange is required for forward secrecy of the connection, you'd want to avoid using a weak group here. The generic group exchange
diffie-hellman-group-exchange-sha1 could be secure, but that depends on both the server and the client being configured correctly.
- Using SHA-1 in the key exchange loses entropy (as outlined in RFC 4253) if you negotiate an encryption or MAC key longer than 160 bits. Therefore, the most security you can possibly get out of using SHA-1 in the key exchange is 160 bits.
- DSA (
ssh-dss), which uses SHA-1 for signatures, is limited to 1024 bits in SSH, which is far too small for practical security. RSA keys less than 3072 bits also offer less than 128-bit security.
128-bit security is the minimum level of security for practical matters these days. Some organizations have requirements for 192-bit security.
If you can use any of the Ed25519, Curve25519, ECDSA, or ECDH algorithms that OpenSSH supports, these will use stronger hash functions and will avoid your entire problem. They may also be available on older systems. When in doubt, follow the Mozilla recommendations.
