Discussion :

[gitnoob]

Bonjour
j'utilise git sur ubuntu.
jusque là pour m'identifier quand je clone un dépot privé ou quand je fait un git push, je donne mon identidiant et un Personal access tokens.Après chaque git oush, je tapais donc mon identifiant et mon token.

Puis on m'a montré un moyen de ne plus le taper systématiquement en enregistrant un clé ssh.
je fais comme ca :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ssh-keygen -t rsa -b 4096 -C "un_nom_au_hasard"

puis je tape sur entrée pour qu'il sauvegarde ca dans lefichier par défaut dans

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

/home/user/.ssh/id_rsa

puis je tape 2 fois sur entrée pour ne pas avoir de passphrase

puis je vais dans le dossier .ssh et j'ouvre le fichier id_rsa.pub. Je copie la clé publique et je la sauvearde dans mon compte github.
Et effectivement je n'ai plus besoin de donner mes identifiants parès un git push.

Par contre si j'essaye de le faire ailleurs que dans

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

/home/user/.ssh/id_rsa

, on dirzit que ce ca ne marche pas. pourquoi?

Le truc c'est que j'ai 2 compte git : un perso et un pro)
Avant quand je tapais mes identifiants après chaque git, je pouvais donner soit le compte perso soit le compte pro.

Maintenant, imaginons que j'ai enregistré la clé ssh avc mon compte pro. et que je veux bosser sur un projet perso.
je n'ai plus envie de taper mes identifants apr_s chaque git push. j'ai donc refait la manip pour enregistrer une clé ssh avec mon compte perso.
mais quand je fais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ssh-keygen -t rsa -b 4096 -C "un_nom_au_hasard_pour_mon_compte_perso"

et que je tape sur entrée, il me dit que ca va écraser ce qu'il ya sur /home/user/.ssh/id_rsa

puis je continue la manip et à la fin je comprends que je ne peux plus utiliser mon compte pro.

comment faire pour avoir 2 comptes git?
car si je le met ailleurs que dans /home/user/.ssh/id_rsa c ne marche pas

[Obsidian]

Bonjour,
Avant toute chose, qu'entends-tu ici par « Personal Access Token » ? Est-ce que ce jeton se résume au final à un simple mot de passe ou s'agit-il d'un truc variable style RSA SecureID ? Dans ce dernier cas, tu risques d'avoir effectivement besoin de mettre en place une clé, mais ce qui suit reste bon à prendre pour travailler avec les autres dépôts, spécialement s'ils sont publics.


C'est effectivement un problème, parce que c'est la solution vers laquelle on renvoie systématiquement les gens, spécialement sur StackOverflow, et ce n'est pas la première approche à suivre avec Git car ce sont deux choses différentes.

• L'authentification de confiance avec ssh en général ;
• L'authentification de confiance avec git en particulier.

L'idée est que pour faire ses transferts, Git n'a en fait besoin que de « voir » le système de fichier distant. De là, trois possibilités : soit le protocole « git:// » (nécessite le lancement d'un dæmon serveur), soit le « http:// » (suffisant pour redescendre des fichiers et même pour en envoyer avec PUT, utilisée par défaut sur les forges logicielles publiques), soit le bon vieux SSH, utilisé par Git pour se connecter à un dépôt distant s'il ne peut pas le voir directement en local.

Or, quand on travaille avec SSH avec plusieurs machines (réelles ou VM), on a souvent le même problème : obligation de re-saisir le même mot de passe des dizaines de fois durant une session de travail. Sauf que dans « ssh — Secure SHell », il y a « secure » et qu'il est par nature intransigeant sur la sécurité (beaucoup plus que rsh ou uucp). Par exemple, il n'est pas possible de passer un mot de passe en tant qu'option sur la ligne de commande de ssh ou scp, ce qui au passage rend impossible l'utilisation de scripts avec ces commandes et cette seule méthode d'authentification. Si un mot de passe est demandé, il le sera de façon interactive avec l'utilisateur depuis le terminal.

En conséquence, toujours avec SSH, lorsque l'on est amené à naviguer fréquemment d'un shell à l'autre, on met en place une infrastructure basée soit sur une API reconnue telle que GSSAPI ou des choses comme PAM, soit avec une infrastructure à clés publiques. En général, ces clés sont ensuite placés dans un trousseau au niveau du système et sont déverrouillées en une fois avec un master password au début de la session de travail ou la première fois que l'on en utilise une. Ensuite, on se considère en environnement sécurisé et ssh ne nous embête plus avec les authentifications même si, sous la table, les serveurs respectifs continuent à s'échanger les clés à chaque nouvelle connexion.

C'est bien beau mais l'ennui avec cela est que :

• En fait, à aucun moment cela ne concerne Git ;
• Avec un master password, TOUS les serveurs se retrouvent déverrouillés en même temps, y compris ceux qui ne sont pas des dépôts Git.

Si cela semble être la solution recherchée, c'est parce que comme ssh ne demande plus de mot de passe à Git, Git ne nous le demande plus non plus.

En fait, Git a bien un dispositif prévu pour ce cas-là : le Git Credential Storage. Mais alors pourquoi cette approche est-elle si souvent suggérée pour Git ? Parce qu'il semblerait que le module concerné ne fonctionne pas (ou mal) sous Windows (ou parfois pas installé par défaut) et que cela concerne donc beaucoup de monde, et parce que dans certains cas, l'intermittence de la demande de mot de passe peut être mal gérée par les environnements de développement qui ne sont pas prévus pour. (Bon en réalité, quand je dis « souvent », je ne suis en fait tombé récemment que sur un post en anglais traitant du même sujet. Il est possible que nous ayons lu le même).

Sous Linux, par contre, ça ne pose aucun problème. Soit tu ajoutes ceci à ton ~/.gitconfig général dans ton home :

Code Git :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
[credential]
        helper = cache --timeout=1200

Soit tu écris en ligne de commande :

Code Shell :

Sélectionner tout - Visualiser dans une fenêtre à part

$ config --global --replace-all credential.helper "cache --timeout=1200"

… ce qui revient au même.

La « mise en cache » consiste à adopter grosso-modo le même comportement que sudo : il va se souvenir de ton mot de passe pendant un certain temps depuis la dernière commande tapée qui le nécessite, ici 1200 secondes (20 minutes). Tu peux changer cette valeur à loisir. L'avantage est que tu peux préciser cette option soit au niveau global, comme on vient de le faire, auquel cas ce sera le comportement adopté à défaut
d'autre chose (ce qui ne t'empêche pas de mettre en place une clé SSH vers un serveur en particulier) ou au niveau local, dans un dépôt : dans ce cas, tu ne bénéficieras de ce service que dans ledit dépôt et Git continuera à te demander ton mot de passe pour chaque transaction serveur dans tous les autres.

[gitnoob]

Avant toute chose, qu'entends-tu ici par « Personal Access Token » ? Est-ce que ce jeton se résume au final à un simple mot de passe ou s'agit-il d'un truc variable style RSA SecureID ? Dans ce dernier cas, tu risques d'avoir effectivement besoin de mettre en place une clé, mais ce qui suit reste bon à prendre pour travailler avec les autres dépôts, spécialement s'ils sont publics.

par personnal access token, je parle de ca (voir screenshot):
je clique sur Tokens (classic)


je vais tester avec le .gitconfig, je suis pas sûr d'avoir compris ce que tu as ecris mais je vais essayer

[JeitEmgie]

Rien ne vous empêche d'une part de créer autant de clés que vous voulez du moment de leur donner un nom différent, et d'autre part d'utiliser la même clé pour vous connecter à différents comptes,
vous configurez soit dans le client GiT, par exemple le panneau Authentication de SmartGit ou dans .ssh/config avec des entrées Host:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
Host mygit.com
  User perso
  IdentityFile ~/.ssh/id_rsa_perso
Host mygit.com
  User pro 
  IdentityFile ~/.ssh/id_rsa_pro

[Obsidian]

je vais tester avec le .gitconfig, je suis pas sûr d'avoir compris ce que tu as ecris mais je vais essayer

Merci pour le screenshot.

En résumé, tu continues avec des mots de passe (et donc tu ne t'embêtes pas à déclarer des clés dédiés sur Github) mais tu demandes à Git de « retenir » ton mot de passe pendant un certain temps, comme le fait sudo, pour éviter d'avoir à le re-saisir à chaque fois.

Et si tu mets cela dans ta config globale, ce sera le comportement par défaut utilisé avec tous les dépôts Git, même ceux qui n'ont pas été explicitement configurés pour ça.

Pour moi, c'est sans conteste la meilleure approche car ça évite d'oublier son mot de passe car on le saisit quand même deux ou trois fois par session. Le dépôt reste protégé par défaut depuis la console et on évite de déposer des choses spécifiques en distanciel autre que le contenu suivi lui-même.