Are the sha1 hashes used by common ssh configurations insecure?

Rule of thumb: SHA1 is potentially insecure when used on relatively static data, e.g. code signing, digital signatures, file hashes.

This is reflected by the PCI FAQ:

• What is the Council’s guidance on the use of SHA-1?

When a hash function is applied iteratively (e.g. HMAC, PBKDF2) it is substantially less affected by collisions than their underlying hash functions per se. Ref. HMAC (Wikipedia). HMAC-SHA1 (and HMAC-MD5) are still safe from a security perspective (in 2019).

Similarly, the dynamic nature of Diffie-Hellman means its weaknesses resides on the number of bits governing its primes rather than the hash function it employs. Elaborating on what ConsideredHarmful noted: diffie-hellman-group14-sha1 is safe because it utilizes a 2048-bit prime whereas diffie-hellman-group1-sha1 is not because it only uses 1024-bits.

None of these findings are critical, they are simply best-practice. There is no practical general attack on SHA1 better than brute force (as of this writing). Natanael correctly pointed out in the thread above that SHA1 collisions do not break hmac-sha1.

diffie-hellman-group14-sha1 is still acceptable for PCI as it is a 2048-bit group: https://weakdh.org/sysadmin.html.

This is equivalent to a ~112 bit symmetric key (the effective security of 3DES) which is considered acceptable by NIST until 2023 (see Table 1, page 128 of NIST SP800-131A rev 2).

For AES key exchange, if you wish to maintain >= 128 bits of security, you should probably be using a DH group >= 3200 bits (see RFC-3526). The smallest group that meets this requirement is diffie-hellman-group16-sha512 (See RFC-5656).

If you can safely drop support immmediately for non-elliptic curve key exchange and SHA1-based HMACs then do so. Otherwise, start planning now as cryptographic migration projects are a huge pain and you will probably need to do so eventually.

Note that some FIPS requirements mandate the use of hmac-sha1.