Change Details

**Context** Split from T2182. Some of the SSH keys defined in [[ https://devcentral.nasqueron.org/source/operations/browse/main/pillar/core/users.sls | 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 messages like: 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] 2025-11-09T15:35:05.633129+00:00 zonegrey sshd-session[674317]: userauth_pubkey: signature algorithm ssh-rsa not in PubkeyAcceptedAlgorithms [preauth] In both cases, we don't have the username directly, we need to parse adjacent lines for that. **Deliverable** * Python script to read /var/log/auth.log and extract usernames trying to login with old SSH client * Create [[ https://devcentral.nasqueron.org/maniphest/task/edit/form/5/ | one security issue task ]] per user concerned **References** * Gaëtan Leurent and Thomas Peyrin. 2020. “[[ https://www.usenix.org/conference/usenixsecurity20/presentation/leurent | SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and Application to the PGP Web of Trust ]]” In Proceedings of the 29th USENIX Security Symposium (USENIX Security 20), 1839-1856. USENIX Association. * [[ https://www.openssh.org/txt/release-8.8 | OpenSSH 8.8 release notes ]]. 2021.

**Context** Split from T2182. Some of the SSH keys defined in [[ https://devcentral.nasqueron.org/source/operations/browse/main/pillar/core/users.sls | 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 [[ https://devcentral.nasqueron.org/maniphest/task/edit/form/5/ | one security issue task ]] per user concerned **References** * Gaëtan Leurent and Thomas Peyrin. 2020. “[[ https://www.usenix.org/conference/usenixsecurity20/presentation/leurent | SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and Application to the PGP Web of Trust ]]” In Proceedings of the 29th USENIX Security Symposium (USENIX Security 20), 1839-1856. USENIX Association. * [[ https://www.openssh.org/txt/release-8.8 | OpenSSH 8.8 release notes ]]. 2021.

**Context** Split from T2182. Some of the SSH keys defined in [[ https://devcentral.nasqueron.org/source/operations/browse/main/pillar/core/users.sls | 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 messages like: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] In both cases, we don't have the username directlyJust after (grep -A 5 or grep on the pid), we need to parse adjacent lines forwe 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 [[ https://devcentral.nasqueron.org/maniphest/task/edit/form/5/ | one security issue task ]] per user concerned **References** * Gaëtan Leurent and Thomas Peyrin. 2020. “[[ https://www.usenix.org/conference/usenixsecurity20/presentation/leurent | SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and Application to the PGP Web of Trust ]]” In Proceedings of the 29th USENIX Security Symposium (USENIX Security 20), 1839-1856. USENIX Association. * [[ https://www.openssh.org/txt/release-8.8 | OpenSSH 8.8 release notes ]]. 2021.