The security branch of my company worries that the use of older versions of OpenSSH (pre-7.4), where the only Key Exchange Algorithm available is SHA-1 is a major security issue. They suggest generating new public/private keypairs for all users in the infrastructure.

As a Linux admin I'm supposed to be making a plan for fixing this issue, but when I try to research it, it seems that there is some mixup between the algorithm used to generate private/public keypairs, and the algorithms used in the connection handshake between two hosts.

As far as I can tell, the SHA-1 hashing algorithm is only used in the key exchange between two hosts, to validate each other, and has nothing to do with generating the public/private keypairs.

It also seems that the demonstrated vulnerability applies to things such as pdf documents, where there are tons of metadata that can be tweaked to try to generate an identical hash without actually generating visible text. I'm not even sure this is possible to implement in the SSH handshake.

My big question is: If our servers are vulnerable because they use SHA-1 in the handshake, what are the worst case scenarios?

  • Can the attacker spoof a known host and capture sensitive information by having an unknowing user log into it?
  • Can the attacker get a hold of login info directly or indirectly?
  • Something else?

Please also correct me if I have misunderstood something, I have found a lot of conflicting information about this!


2 Answers 2


SSH uses a hash algorithm in couple of places:

  1. As a pseudo-random function in the key exchange (e.g., with diffie-hellman-group14-sha1).
  2. As a message authentication code (e.g., hmac-sha1)
  3. To sign a signature over the negotiated session hash to authenticate both parties (e.g., with ssh-rsa)
  4. 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:

  1. It's weak in many practical cases and we prefer to use cryptographic primitives which are unambiguously strong.
  2. 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.
  3. 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:

  1. 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.
  2. 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.
  3. 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.

  • It isn't clear if SSH the protocol limits DSS=DSA to 1024. rfc4253 references 186-2 which as of 2006 (with change notice 1) specified 1024/160 and SHA-1, and 4253 explicitly confirms SHA-1 but not 1024 or 160. OpenSSH the implementation will generate (in ssh-keygen) only 1024/160, but will use (in sshd and ssh) a DSA key generated e.g. in OpenSSL with larger p and even q, but with SHA-1 as explicitly required in 4253 thus losing the benefit. The 4253 scheme ssh-rsa also does any RSA size even 3072 with SHA-1, but rfc8332 schemes rsa-sha2-(256,512) fix this. Sep 20, 2020 at 2:06
  • True, it's theoretically possible to generate larger DSA keys, but I'm not aware of any implementations which do that and not sure if they're interoperable across implementations. I'm aware of RSA SHA-2, which is a good choice if you need RSA, but that doesn't help the OP who needs older system support. Ed25519 is a better choice when possible because it's much easier to make constant time.
    – bk2204
    Sep 20, 2020 at 16:25
  • I don't quite understand why Use 3 is considered unfeasable; is it because the attacker would need to guess the output of the pseodu-random function from Use 1, in a short timespan?
    – Pepe
    Sep 24, 2020 at 11:09
  • 1
    Correct, and because the key exchange is single use. A collision attack requires finding two messages that hash to the same value, so an attacker would have to create an exchange hash that is of a certain form and then cause a subsequent key exchange to use a similar exchange hash, which would require guessing the result of that key exchange in advance.
    – bk2204
    Sep 24, 2020 at 11:26
  • 1
    Correct. Being able to create a hash collision doesn't leak the private key if that hash is used, at least not for the algorithms we use for SSH. The attacker would only be able to guess the hash if the server colluded with it or re-used the ephemeral DH or ECDH key pair. While the latter doesn't necessarily break the security of TLS, it's much riskier in SSH, and I'm not aware of any implementations which do that.
    – bk2204
    Sep 24, 2020 at 22:23

Note that I'm not an expert in cryptography, so maybe ask this question too at crypto.se. From my understanding there are 3 places where SHA-1 was used and where it gets disabled now:

  1. Use as hash algorithm when generating the keys during the key exchange
  2. Use as signature algorithm to verify the public key of the peer
  3. Use as signature algorithm within a certificate hierarchy (PKI), so that one only need to trust an issuing CA and not each key

During the key exchange (#1) public/private keys are not involved so any weaknesses of SHA-1 in this place does not compromise the key pairs. It most it could compromise the single connection but even this is IMHO currently practically impossible since SHA-1 is just used as a hash and not for signing, i.e. collision and pre-image attacks are irrelevant here.

During authentication (#2) SHA-1 gets used as signature. A weak signature hash does not compromise the key pairs but at most would allow authentication of somebody not having the correct key pair. Even this is IMHO currently practically impossible, since without having access to the real key pair it is impossible to predict and fake the expected signature.

Use of SHA-1 as signature within a PKI (#3) is different though. A weak signature algorithm would allow the creation of a certificate which seems to be signed by the trusted CA and is thus accepted for authentication. The attacker has also sufficient time to create such a faked certificate.

In summary: No key pairs are compromised.
But if there was a PKI involved which used SHA-1 for signing, then a) SSH clients and servers should be hardened to no longer accept SHA-1 as certificate signature and b) all certificates signed with SHA-1 need to be replaced because they will no longer be accepted.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .