Pourquoi GitHub a soudainement refusé une clé SSH : le fichier `.pub` disparu

• Sur un portable inchangé, un git pull vers GitHub s’est soudainement mis à échouer, puis l’authentification a refonctionné après avoir généré le fichier .pub correspondant à la clé privée
• Lorsqu’un fichier .pub est présent, OpenSSH présente d’abord la clé publique, obtient une approbation, puis signe ; en son absence, il envoie immédiatement une requête d’authentification signée
• Les deux flux sont conformes à RFC 4252 et généralement acceptés par sshd, mais le frontal SSH de GitHub à ce moment-là ne semblait pas accepter les requêtes directement signées
• Lors de 12 essais contrôlés, les 6 cas sans fichier .pub ont tous été refusés, tandis que les 6 cas avec le fichier ont tous réussi
• Un changement dans la bannière du serveur laisse supposer une possible modification côté serveur, mais la cause exacte n’a pas été confirmée ; il est donc prudent de conserver aussi le fichier de clé publique correspondant

---

Échec soudain de l’authentification et résolution

• Sur le portable principal, git pull s’arrêtait avec l’erreur Permission denied (publickey)
  • La clé était pourtant toujours enregistrée sur GitHub
  • Sur un autre portable utilisant une autre clé, le même dépôt pouvait être récupéré normalement
• Aucun problème n’a été trouvé dans la clé ou la configuration du client
  • openssl rsa -check renvoyait RSA key ok
  • L’algorithme de signature récent rsa-sha2-512 était utilisé
  • Il n’y avait pas de problème dans ~/.ssh/config et la page d’état de GitHub était normale
• Après une réinstallation, le fichier de clé publique correspondant à ~/.ssh/github_rsa avait disparu ; une fois recréé avec la commande suivante, l’authentification a réussi

ssh-keygen -y -f ~/.ssh/github_rsa > ~/.ssh/github_rsa.pub

• Lors des essais contrôlés, les 6 tentatives sans fichier .pub ont toutes échoué, et les 6 avec le fichier ont toutes réussi

Un flux d’authentification différent selon le fichier .pub

• OpenSSH utilise deux flux d’authentification par clé publique différents selon la présence du fichier .pub
  • Si le fichier existe, la clé publique est d’abord présentée au serveur, puis la signature est envoyée après approbation
  • Si seule la clé privée est présente, l’étape de vérification préalable est ignorée et une requête d’authentification entièrement signée est envoyée directement
• Les deux méthodes sont autorisées par RFC 4252, et un sshd classique accepte les deux
• Sur GitHub à ce moment-là, les requêtes de clé publique directement signées étaient rejetées, mais il n’a pas été possible de confirmer s’il y avait eu un vrai changement côté GitHub
  • Dans les journaux de debug, la bannière du serveur n’apparaissait plus au format historique babeld-<hash>, mais comme 6a2c000
  • L’hypothèse selon laquelle un nouveau logiciel serveur aurait rejeté les requêtes directement signées reste une supposition
• Pour éviter le même problème, il faut conserver aussi le fichier .pub correspondant à la clé privée

[GN⁺]

Avis sur Lobste.rs

• Je rencontre le même problème depuis 4 heures, et il est déjà signalé sur https://www.githubstatus.com/incidents/g40zcbvchny4

• Il y a quelques semaines, en remplaçant ma clé SSH, je n’avais pas supprimé l’ancien fichier .pub ignoré par Git, et l’accès continuait d’échouer même avec la nouvelle clé
  Ce n’est qu’après avoir activé plusieurs options de débogage que j’ai découvert que le client SSH envoyait l’ancienne empreinte ; je ne savais même pas qu’OpenSSH lisait le fichier .pub, et je l’avais toujours considéré comme totalement inutile

• Aujourd’hui, mon serveur CI a subi la même panne : impossible soudainement de se connecter à github.com
  En remplaçant la clé par la bonne clé ed25519, tout a refonctionné, mais cette clé non plus n’a pas de fichier .pub associé, donc je ne sais pas pourquoi cela a résolu le problème

  • Quand la clé a cessé de fonctionner brusquement, j’ai d’abord craint une compromission, donc c’est rassurant de voir que GitHub semble maintenant intervenir directement

• J’ai eu le même problème aujourd’hui, et à ma connaissance GitHub n’avait pas annoncé de changement de comportement de l’authentification SSH

  • Cela ne semble probablement pas être un changement planifié

• Après avoir perdu à la fois mon mot de passe et ma clé de récupération, j’ai suivi la procédure de récupération de compte basée sur une clé SSH, mais GitHub a expiré cette clé SSH, ce qui m’a fait perdre complètement l’accès au compte

• Cela fait 7 ou 8 ans que je n’ai probablement pas de fichier .pub, donc j’espère que le problème sera résolu avant ma prochaine utilisation de GitHub

  • Le fichier de clé publique peut être régénéré facilement, et la commande figure aussi dans l’article d’origine

• Si les deux flux d’authentification sont valides, je me demande pourquoi le flux de découverte de clés existe
  Il semble seulement provoquer ce genre de comportement étrange, et puisqu’on peut de toute façon générer la clé publique à partir de la clé privée, SSH pourrait sans doute le gérer automatiquement

  • C’est utile quand la clé privée est chiffrée ou stockée sur un jeton matériel de sécurité et ne peut pas être utilisée immédiatement
    SSH vérifie d’abord quelles clés fonctionneront sur le serveur, afin d’éviter que l’utilisateur ne déchiffre inutilement une clé qui échouera de toute façon à l’authentification
    Ce comportement a aussi des effets de bord particuliers, comme avec https://github.com/FiloSottile/whoami.filippo.io, donc il faudrait également permettre un mode où le serveur doit déjà connaître la clé publique du client avant même qu’une tentative d’authentification soit autorisée, au cas où l’utilisateur se connecterait par erreur au mauvais serveur

• Mon compte Office 365 professionnel a lui aussi cessé soudainement de fonctionner aujourd’hui pour la première fois en 5 ans
  Je me demande si Microsoft a subi une compromission et réappliqué un salage à toutes les valeurs, ou si cela ne touche que les utilisateurs européens à cause du récent vote sur Chat Control 1.0

  • Le service de terminaison de connexion de GitHub et l’authentification des comptes M365 n’ont absolument rien à voir, et je suis sûr à 99,999 % que c’est une coïncidence
    Je peux l’affirmer avec suffisamment d’assurance, étant l’une des deux personnes que je connais ayant travaillé à la fois sur les Git Systems de GitHub et sur la suite de produits Office/M365 de Microsoft
    Même si une politique ou un changement technique commun aux deux services en était la cause, ce sont des systèmes séparés, donc il est extrêmement improbable qu’ils soient déployés le même jour