Page MenuHomeDevCentral

Detect legacy SHA-1 RSA keys
Open, WishlistPublic

Description

Context

Split from T2182.

Some of the SSH keys defined in pillar/core/users.sls still use RSA algorithm. This is fine with rsa-sha2-256 signing updated algo, but not with an sha-1 signature. From the same key, it's possible to derive a signature that depends of the old SSH client.

OpenSSH 8.8+ disabled by default this algo, as collisions have been demonstrated for SHA-1.
Both Debian 13 (Trixie) and FreeBSD 14 uses recent OpenSSH version, so users with older SSH clients can't login anymore to Eglide.

We need to detect and reach relevant users to update their SSH client.

Non-plan

To check the content of the key itself isn't interesting. For example, with recent OpenSSH, ssh-keygen -lf with a path to the public key file will emit a SHA-256 hash.

The key itself isn't the issue, the signature emitted by the OpenSSH client is.

Plan

We can analyze /var/log/auth.log to detect keys.

AFAIK, two messages are relevant.

(1) Negotiation between the server and a client without support for any elliptic key

2025-11-09T02:07:25.520735+00:00 zonegrey sshd-session[661214]: Unable to negotiate with <ip> port 38346: no matching host key type found. Their offer: ssh-rsa,ssh-dss [preauth]

In that scenario, the incident occurs before the username is sent, so, that's unfortunately not actionable (and dubious, could be for a force-brute attack).

· · ─ ·✶· ─ · ·

(2) SSH server and client can communicate, but key is sent with legacy ssh-rsa signature

2025-11-09T15:35:05.633129+00:00 zonegrey sshd-session[674317]: userauth_pubkey: signature algorithm ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]

Just after (grep -A 5 or grep on the pid), we should have a message Connection closed by authenticating user <username> and that's a win.

Deliverable

  • Python script to read /var/log/auth.log and extract usernames trying to login with old SSH client
  • Create one security issue task per user concerned

References

Event Timeline

dereckson triaged this task as Wishlist priority.Sun, Nov 9, 23:59
dereckson created this task.

Bruteforce attack scenario possible, so we're only interested by usernames defined in users.sls, not by "root" (can't login by SSH) or generic accounts like "docker" (doesn't exist):

2025-11-03T21:01:55.939248+00:00 zonegrey sshd-session[547800]: userauth_pubkey: signature algorithm ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]
2025-11-03T21:01:55.939248+00:00 zonegrey sshd-session[547800]: userauth_pubkey: signature algorithm ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]
2025-11-03T21:02:05.816372+00:00 zonegrey sshd-session[547800]: Connection closed by authenticating user root 139.19.117.130 port 48144 [preauth]
2025-11-03T21:02:05.816372+00:00 zonegrey sshd-session[547800]: Connection closed by authenticating user root 139.19.117.130 port 48144 [preauth]