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 contain legacy RSA keys with SHA-1 signature (`ssh-rsa` type). 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 SHA-1 keys can't login anymore. We need to detect and reach relevant users to update their keys. **Deliverable** * Python script in rOPS utils/ directory to read keys and output the pair {username, legacy SSH key} * 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: 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 contain legacy RSA keys with SHA-1 signature (`ssh-rsa` type).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] Both Debian 13 (Trixie) and FreeBSD 14 uses recent OpenSSH version, so users with SHA-1 keys can't login anymore. 2025-11-09T15:35:05.633129+00:00 zonegrey sshd-session[674317]: userauth_pubkey: signature algorithm ssh-rsa not in PubkeyAcceptedAlgorithms [preauth] We need to detect and reach relevant usersIn both cases, we don't have the username directly, we need to update their keysparse adjacent lines for that. **Deliverable** * Python script in rOPS utils/ directory to read keys and output the pair {username, legacyto read /var/log/auth.log and extract usernames trying to login with old SSH key}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.