Ajouter un jeton daccès personnel à git

J’utilise mon nom d’utilisateur-mot de passe GitHub pour m’authentifier auprès de GitHub via Git CLI depuis longtemps maintenant. GitHub a annoncé en juillet de l’année dernière qu’il allait passer à l’utilisation de l’authentification basée sur des jetons pour toutes les opérations Git authentifiées (clonage de dépôts privés, push, etc.) À partir du 13 août 2021, toute opération authentifiée nécessitera une authentification basée sur des jetons (jetons d’accès personnels, OAuth, etc.). À cette fin, GitHub envoie des e-mails à ses utilisateurs chaque fois qu’ils effectuent une opération Git authentifiée à l’aide de mots de passe (une fois par jour). Je reçois ces avis de dépréciation depuis un an maintenant et j’ai été paresseux à ce sujet. J’ai finalement pris mon envol et j’ai configuré Git CLI pour utiliser des jetons d’accès personnels (PAT).

Ancienne configuration

que j’utilisais pour enregistrer mon nom d’utilisateur-mot de passe GitHub. Cela m’a permis d’éviter d’avoir à entrer mes informations d’identification à chaque fois que j’exécutais clone/push.

La façon dont cela fonctionne est la suivante : vous exécutez

et la prochaine fois que vous effectuez une extraction/poussée/clonation, vous serez invité à entrer des informations d’identification, qui seront stockées et utilisées lors des opérations suivantes. J’ai appris aujourd’hui qu’il stocke en fait ces informations en texte brut sous .

Aïe! Cela me sert bien pour copier aveuglément des commandes de StackOverflow.

En le réparant,

je m’étais déjà adapté à l’utilisation des PAT. Je les utilise pour travailler avec des dépôts sur un VPS. Ils sont très intéressants, car vous obtenez des autorisations granulaires et chaque machine peut avoir son propre jeton, donc au cas où un jeton serait compromis, vous pouvez simplement le révoquer, en créer un nouveau et vous mettre en route.

Je voulais que mon jeton soit stocké sur ma machine et je voulais qu’il soit stocké en toute sécurité. En cherchant des solutions, j’ai appris que Mac et Windows ont des magasins d’informations d’identification dédiés qui stockent les secrets en toute sécurité et s’intègrent bien à git. Je Je n’ai pas pu trouver une telle solution native pour Linux, c’était soit des solutions tierces, soit des solutions faites à la main (que je n’envisagerais jamais en matière de sécurité), soit du texte simple.

J’ai levé les yeux pour voir s’il y avait un assistant d’accréditation disponible pour WSL. J’ai trouvé cette excellente documentation qui décrit l’utilisation du Gestionnaire d’informations d’identification Windows à partir de WSL pour accéder aux secrets.

La façon dont cela fonctionne est qu’il utilise le gestionnaire d’informations d’identification Git (GCM) sur l’installation Windows de Git (vous devez avoir installé Git pour Windows) qui à son tour communique avec le gestionnaire d’informations d’identification Windows pour récupérer le secret.

La première chose que j’ai faite a été de supprimer le fichier.

L’exécution de la commande below définit l’assistant d’informations d’identification de WSL distro sur le GCM Windows :

et la prochaine fois que vous clonez/poussez/tirez ou effectuez une opération nécessitant une authentification, une invite de connexion s’ouvre.

Maintenant, c’est possible fonctionne de 2 manières -

1. Si vous cliquez sur le bouton « Se connecter avec GitHub », il s’authentifiera via OAuth et enregistrera le jeton oauth dans le Gestionnaire d’informations d’identification Windows
2. Si vous fermez l’invite, il vous demandera le nom d’utilisateur et le mot de passe. Vous pouvez entrer votre nom d’utilisateur GitHub et, à la place du mot de passe, entrer le PAT que vous avez créé à partir des paramètres GitHub. Cette paire nom d’utilisateur-jeton sera ensuite enregistrée par le Gestionnaire d’informations d’identification Windows.

J’ai choisi cette dernière option pour les raisons mentionnées précédemment.

Conclusion

La configuration de l’interface de ligne de commande Git pour utiliser les PAT GitHub et leur stockage local en toute sécurité était assez simple. Je regrette d’avoir retardé de le faire d’un an. Une autre alternative que j’ai examinée était d’utiliser SSH, et il existe une excellente documentation de GitHub pour cela. J’ai choisi de ne pas l’utiliser dans ce cas car cela m’obligerait à changer de télécommande URL de HTTPS à SSH, et je suis trop paresseux pour m’en soucier. Cependant, je l’essaierai la prochaine fois que je devrai configurer une nouvelle machine.