GitHub autorise les clés de sécurité pour ses accès OpenSSH
Le 11 mai 2021 à 07h22
2 min
Logiciel
S'il était déjà possible de « bidouiller » une telle solution par le passé, un support a été introduit il y a quelques mois via les standard FIDO et U2F, évitant de se reposer sur des intégrations tierces.
Rares sont pour le moment les services à le proposer, c'est désormais le cas de GitHub, qui détaille la procédure à suivre au sein de sa documentation. OpenSSH 8.2 ou supérieur est nécessaire. Sous Windows, dont le portage est encore en 8.1, il faudra en passer par Cygwin.
Pour profiter de cette fonctionnalité, il faudra générer une nouvelle paire de clés nécessitant la présence d'une clé de sécurité physique pour être activée. Deux types sont proposés, chacun utilisant un algorithme différent : ecdsa-sk et ed25519-sk. Une fois générée, la clé publique doit être ajoutée au compte GitHub. Elle se gère comme n'importe quelle autre.
Yubico précise que si ses produits sont compatibles, les modèles FIDO2 permettent de générer une paire de clés « résidente », dont la partie privée est stockée au sein de l'élément de sécurité de la clé physique. Elle peut donc être transportée sans crainte qu'un tiers n'y accède.
Le 11 mai 2021 à 07h22
Commentaires (12)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 11/05/2021 à 08h30
#1
Bonjour,
Je remarque souvent que NXI parle de la marque Yubico, mais assez peu du concurrent allemand Nitrokey. Quelle en est la raison ?
Toujours à ce sujet : peut-on espérer un test comparatif entre Yubico, Nitrokey et Solokeys ?
Le 11/05/2021 à 09h14
#1.1
On a déjà parlé des nitrokey/solo (qu’on a même testé). C’est juste que Yubico est plutôt proactif sur ce genre d’annonces avec de nouveaux modèles/couches logicielles annoncés régulièrement. Pour le reste, une clé de sécurité répondant au standard fonctionne comme une autre, il n’y a pas vraiment matière à comparaison outre mesure.
Le 11/05/2021 à 10h12
#2
J’ai un peu de mal à comprendre le principe. Si mon accès est protégé par une paire de clés SSL, GitHub connaît ma clé publique, mais ma clé privée n’est que sur mon propre PC et nulle part ailleurs.
J’ai déjà du 2FA puisque (1) je dois être en possession de mon PC avec ma clé privée, et (2) je dois connaître le mot de passe permettant de déchiffrer icelle.
Je conçois qu’on puisse vouloir ajouter une couche pour “compliquer” le déchiffrement de la clé privée au cas où mon PC est compromis/volé, mais en quoi cela concerne-t-il Github ou n’importe quel autre serveur utilisant SSH? Ce déchiffrement, par définition, ne peut se faire que sur ma machine…
Plus précisément, je ne comprends pas ce que Github doit faire de son côté dans un tel scénario.
Et si GitHub se pare d’une solution où en plus de la sécurisation SSL il faut parallèlement fournir une identification par une clé de sécurité physique, cette solution s’applique aussi si j’accède à git par https:// au lieu de ssh:
Le 11/05/2021 à 12h01
#3
???
Avant tu pouvais te connecter a github par SSH avec une clé classique (=chaine de texte) => si tu te fais voler cette chaine de texte, l’attaquant à accès à ton compte github
Maintenant tu peux te connecter a github par SSH avec une une clé sécurisée (chaine de texte + yubico) => si tu te fais voler la chaine de texte, l’attaquant n’à pas accès à ton compte car il faut obligatoirement le token physique pour l’authentification.
Voila. Rien de plus, rien de moins. Bref, dans github tu pouvais utiliser une clé ssh “ed25519”. Maintenant tu peux utiliser une clé “ed25519-sk” et laisser la magie de yubico s’opérer.
Le 11/05/2021 à 13h08
#3.1
Je continue à ne pas comprendre. La “clé classique” est stockée sur ma machine et n’est jamais transmise. La clé classique est chiffrée -> je dois entrer un MDP pour la déchiffrer LOCALEMENT sur ma machine. Ce MDP est inconnu de Github.
En gros, quand je me logge, Github me dit “voici un message chiffré avec ta clé publique, prouve-moi que tu connais la clé privée en me renvoyant la version déchiffrée”. Cette preuve n’implique jamais que la crlé privée soit transmise, elle reste sur mon PC. Que cette clé soit protégée par une simple passphrase, qu’elle soit stockée dans la secure enclave, ou qu’elle soit traitée par une yubikey ne change rien au protocole…
Le 11/05/2021 à 13h21
#4
Comme expliqué dans l’article et celui consacré au sujet, c’est une fonctionnalité mise en place il y a quelques mois dans OpenSSH 8.2 qui nécessite d’utiliser un algo spécifique à la création de la clé. GitHub dit donc qu’il gère cette solution en plus des méthodes classiques.
Le 11/05/2021 à 13h46
#4.1
Merci pour ces précisions. Donc ce que j’en comprends c’est que (1) le traitement est effectivement exécuté sur ma machine sans impact sur le serveur, mais (2) les clés ainsi générées ont un type qui se termine par “-sk”, donc GitHub n’a rien à faire, si ce n’est accepter ce type de clé (et en interne ignorer ce suffixe, gérer une 25519-sk comme si c’était une 25519)
Le 11/05/2021 à 13h36
#5
Euh juste pour préciser, les chaînes que tu rentres sur github sont tes clés publiques, ce n’est pas un souci de se les faire piquer. D’ailleurs elles sont publiquement disponible: pour un utilisateur nommé “azerty”, il suffit d’aller à github.com/azerty.keys
C’était effectivement possible avant, mais on dirait que les clients ssh ont été améliorés depuis la dernière fois que j’ai regardé, avec notamment l’addition d’un nouveau type de clé
*-sk. Il semble que github accepte juste ce nouveau format, et a ajouté un mini tutoriel. L’essentiel se passe effectivement sur ta machine. D’après l’article de yubico, ça a l’air de se passer un peu comme avec un TPM: une clé secrète est générée sur ton appareil (yubikey, smartcard, jeton U2F ou simplement TPM), qui te la fournit chiffrée pour que tu la stockes. Tu peux y mettre un mot de passe en plus.Lorsqu’il y a besoin d’authentifier un utilisateur, la clé est retransmise au dispositif qui l’a chiffrée, est déchiffrée en interne, mais jamais transmise au PC. Le périphérique attestera juste cryptographiquement de la possession de la clé. Cela nécessite peut-être de légers ajustements du protocole ssh?
Je vais réessayer, si openssh supporte directement FIDO ce sera plus simple et plus portable que configurer GPG et ssh-agent.
Le 11/05/2021 à 13h45
#6
Après, elles n’offrent pas toutes les mêmes fonctionnalités, mais c’est assez vite comparé… Le standard important ici semble FIDO U2F. Perso j’ai une yubikey depuis 6 ans, mais les nitrokeys semblent intéressantes.
Le 11/05/2021 à 17h43
#7
Je parlais de se faire voler sa clé privée, par exemple par un spyware. Empiler les mdp a saisir comme le fait 33A20158* c’est a la fois moins sécurisé et plus chiant que d’avoir une clé physique.
Donc au bout d’un moment, autant investir qq euros dans une clé physique.
Le 12/05/2021 à 06h50
#7.1
Mais à quel moment ai-je dit qu’une clé physique est inutile ? Ma question posait uniquement sur le fait que le serveur devait être au courant que la clé privée est stockée dans une clé sécurisée, alors que ça devrait lui être totalement transparent.
Ma porte d’entrée se fiche éperdument de savoir si la clé vient de ma poche ou de sous le paillasson.
Le 12/05/2021 à 09h05
#8
Ah, ok.
Alors oui, comme le dit la news, on peut toujours “bidouiller” une solution qui sécurise physiquement la clé ed25519.
En reconnaissant directement le protocole “ed25519-sk”, on n’a plus besoin de la bidouille pour github.