Avant de répondre à la question de
Comment gérer plusieurs comptes sur GitHub ? regardons comment GitHub effectue l'authentification.
1) Un seul utilisateur pour tout !
Vous l’avez très certainement remarqué quand vous interagissez avec GitHub vous utilisez toujours le user git. Par exemple :
git clone git@github.com:example/test
Pour accéder à des repositories publics ça ne parait pas surprenant, mais c’est aussi le cas quand on clone un repo privé. Comment github fait-il pour savoir si celui qui lance la commande a le droit d’accéder à ce repository ? Comme le user est toujours le même et qu’il n’y a pas de mot de passe, c’est forcément la clé ssh qui sert à la fois pour l’identification et l’authentification.
Cela implique qu’une même clé ssh ne peut être associée qu’à un seul profil. Si vous tentez de réutiliser une clé déjà associé à un profil vous aurez ce type d’erreur :
Verify public key failed for Example key is already in use.
2) A qui est cette clé ?
Bien sûr il est impossible que quelqu’un d’autre que vous ait la même clé. Si vous avez ce message d'erreur c'est que vous avez un (vieux...) profil qui utilise déjà cette clé. Pour savoir lequel, il suffit d’initier une connexion ssh en ligne de commande en explicitant la clé à utiliser :
ssh -T -ai ~/.ssh/id_rsa git@github.com
Si la clé est connue, la réponse de GitHub sera:
> Hi XXXXXX! You've successfully authenticated,
but GitHub does not provide shell access.
Où XXXXX est le nom du profil utilisant cette clé.
3) Jongler avec les clés
Il faut donc avoir autant de clés ssh que de profils sur GitHub. Le problème est comment indiquer quand on fait une opération avec git quelle clé doit être utilisée ? Une fois de plus c’est le fichier ~/.ssh/config qui va nous sauver.
Il faut créer un host fictif pour chaque profils en spécifiant au moins le véritable hostname et la clé à utiliser pour ce host.
cat ~/.ssh/config
Host Expl
HostName github.com
User git
IdentityFile ~/.ssh/example_id_ed25519
Host Demo
HostName github.com
User git
IdentityFile ~/.ssh/demo_id_rsa
Grace à cela nous pourrons utiliser ces hosts fictifs ainsi :
git clone Expl:example/test
git clone Demo:demonstration/projet-demo
Le host fictif (Expl ou Demo) définit à la fois : le host réel (github.com), le user (git) et la clé à utiliser. Il n’est donc plus nécessaire de spécifier le user (git@Demo ou git@Expl). Il suffira donc de remplacer le classique « git@github.com » par Expl ou Demo suivant le profil que l’on veut utiliser.
.ssh/config : Ref-1 , Ref-2
4) Confiez vos clés à un Agent-ssh
Une autre méthode consiste à charger toutes vos clés privées dans un agent ssh et laisser le protocole SSH essayer chaque clé jusqu’à ce que le serveur en accepte une. L'avantage d'un agent ssh est qu'il s'occupe de demander, si nécessaire, les pass-phrases des clés cryptées. Suivant l'agent il peut faire ça au démarrage, ou bien à la première utilisation de la clé.
- Un premier problème est que certains serveurs limitent le nombre de tentatives de connexion. Si vous avez beaucoup de clés chargées par l’agent-ssh vous risquez d’obtenir « too many authentication errors ».
- Le deuxièmes problème est quand vous avez plusieurs profils (donc plusieurs clés) sur GitHub . Comment savoir si la clé acceptée correspond au bon profil ?
Important: Pour que ssh interroge l'agent ssh il ne faut pas utiliser l'option IdentitiesOnly dans .ssh/config
Windows PuTTY/Pageant : Ref-1 , Ref-2 , Ref-3
Linux ssh-add et ssh-agent : Ref-4 , Ref-5
Résumons
Il y a trois sources possibles pour une clé privée:
a) La clé par défaut id_rsa (ou id_ecdsa
ou id_ed25519 etc…) venant du répertoire .ssh/
(méthode utilisable si on a une seule clé pour tout)
Dans les logs de « ssh –T –v git@github.com » on trouvera cette paire
de lignes Offering/Accepted :
Offering public
key: C:\\Users\\bibi\\.ssh\\id_rsa RSA SHA256:GwKTTsGLCTlq…Ug
Server
accepts key: C:\\Users\\bibi\\.ssh\\id_rsa
RSA SHA256:GwKTTsGLCTlq…Ug
b) La clé associée explicitement au host fictif
dans le fichier .ssh/config
(méthode utilisable quand on doit associer une clé spécifique à certain host ou user@host)
Dans les logs de « ssh –T –v example » on trouvera cette paire de
lignes :
(rappel: example est une host fictif définit dans .ssh/config)
Offering public
key: C:\\path\\to\\file RSA SHA256:GwKTTsGLCTlq…Ug explicit
Server
accepts key: C:\\path\\to\\file RSA SHA256:GwKTTsGLCTlq…Ug
explicit
Notez le ‘explicit’ en fin de ligne.
c) La clé proposée (parmi d’autres) par l’agent ssh :
Dans les logs de « ssh –T –v git@github.com » on trouvera cette paire
de lignes :
Offering public
key: nom_clé RSA SHA256:GwKTTsGLCTlq…Ug agent
Server
accepts key: nom_clé RSA SHA256:GwKTTsGLCTlq…Ug
agent
Notez
le ‘agent’ en fin de ligne.
SOLUTION
Il est évident qu’il faut de la méthode pour ne pas se mélanger
les clés…
- Le comportement par défaut de ssh n'est acceptable que si on a une une seule clé pour tout. Ce qui ne marche pas si vous avez plusieurs comptes GitHub.
- L'agent ssh est obligatoire quand les clés privées sont cryptées avec une pass-phrase. Dans ce cas il est fortement recommandé de le combiner avec la méthode suivante pour rendre le choix des clés prévisible.
- La méthode des hosts fictifs définis dans .ssh/config demande de la configuration et de modifier les url git pour éviter les ambiguités, mais c’est la seule méthode multi-clés dont le comportement est prévisible et sans risque de provoquer des « too many authentication errors ».
Donc ==> .ssh/config + (ssh-agent si pass-phrase)
L'utilisation du fichier .ssh/config donne accès à de très nombreuses options qui vont bien au delà du problème des profils multiples avec GiyHub.
https://www.openssh.com/
