J'ai récemment rencontré un problème où je ne pouvais pas appliquer les modifications dans un référentiel que j'avais cloné en tant qu'autre utilisateur du premier utilisateur avec lequel j'ai poussé dans git sur mon bureau. >
Tentative de transmission des modifications au dépôt et reçois une erreur que l'original le nom d'utilisateur n'a pas l'autorisation, même s'il a été cloné à l'aide de le deuxième utilisateur et plus précisément une clé ssh.
La suppression des entrées git dans le gestionnaire d'informations d'identification Windows n'a pas résoudre ce problème.
La suppression du nom d'utilisateur global et de l'adresse e-mail n'a pas résolu ce problème
J'ai enfin pu appliquer mes modifications en utilisant ce qui suit:
$ ssh -T jjschweigert Hi jjschweigert! You've successfully authenticated, but GitHub does not provide shell access. $ ssh -T schwaggs Hi jjschweigert! You've successfully authenticated, but GitHub does not provide shell access.
Je publie ceci à la fois pour les personnes qui ont rencontré ce problème et aussi pour demander quelques questions,
Je comprends que cette commande spécifie essentiellement la clé que la connexion ssh doit utiliser lorsqu'elle effectue son push, mais pourquoi cette clé n'est-elle pas déjà ciblée si elle a été clonée en utilisant le même fichier d'identité?
Existe-t-il des alternatives à cela ou de meilleures approches qui ne sont pas un travail fastidieux, comme la modification manuelle des valeurs de configuration ou la suppression des entrées du gestionnaire d'informations d'identification Windows?
L'objectif serait donc de pousser les modifications vers plusieurs comptes github sans avoir à faire des choses comme spécifier temporairement la clé ssh à utiliser.
https://github.com/jjschweigert/testrepo
git@github.com:schwaggs/testssh.git
git@github.com:jjschweigert/testrepo.git
$ git push ERROR: Permission to schwaggs/testssh.git denied to jjschweigert. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.
$ git clone schwaggs:schwaggs/testssh.git Cloning into 'testssh'... remote: Enumerating objects: 21, done. remote: Counting objects: 100% (21/21), done. remote: Compressing objects: 100% (11/11), done. remote: Total 21 (delta 0), reused 18 (delta 0), pack-reused 0 Receiving objects: 100% (21/21), done.
$ git push Enumerating objects: 3, done. Counting objects: 100% (3/3), done. Delta compression using up to 12 threads Compressing objects: 100% (2/2), done. Writing objects: 100% (2/2), 261 bytes | 43.00 KiB/s, done. Total 2 (delta 0), reused 0 (delta 0) To jjschweigert:jjschweigert/testrepo.git c082e38..31b7830 master -> master
$ git clone jjschweigert:jjschweigert/testrepo.git Cloning into 'testrepo'... remote: Enumerating objects: 28, done. remote: Counting objects: 100% (28/28), done. remote: Compressing objects: 100% (15/15), done. remote: Total 28 (delta 0), reused 28 (delta 0), pack-reused 0 Receiving objects: 100% (28/28), done.
$ cat ~/.ssh/config Host jjschweigert HostName github.com User git IdentityFile ~/.ssh/jjschweigert_key Host schwaggs HostName github.com User git IdentityFile ~/.ssh/jjschweigert_key
GIT_SSH_COMMAND="ssh -i <path to private ssh key for second user>" git push
3 Réponses :
La suppression des entrées git dans le gestionnaire d'informations d'identification Windows n'a pas résolu ce problème.
Si vous utilisez l'URL ssh (
git@github.com:), le gestionnaire d'informations d'identification n'est pas impliqué: il fournit les informations d'identification pour/ https: //URL uniquement.Utilisez git pour la première fois, qui demande les informations d'identification github lors de la transmission vers un référentiel.
Ce ne serait le cas que si l'URL d'origine distante est une URL https.
Le but serait donc de pousser les modifications vers plusieurs comptes github sans avoir à faire des choses comme spécifier temporairement la clé ssh à utiliser.
Cela se fait via un fichier de configuration ssh: voir comme exemples pratiques:
- " Comment travailler sur le dépôt GitHub personnel à partir d'un ordinateur de bureau dont la clé SSH est déjà ajoutée à un compte GitHub professionnel? a > "
- " Comment configurer l'authentification pour deux comptes GitHub distincts à partir du même client ssh? "
À partir de l'édition
Host user1 HostName github.com User git IdentityFile ~/.ssh/iser1_key <<==== Host user2 HostName github.com User git IdentityFile ~/.ssh/user1_key <<==== same key!? Meaning same user!vous ne pouvez pas vous attendre à pousser en tant qu'utilisateur2, si la configuration SSH pour l'entrée utilisateur2 fait référence à la clé privée utilisateur1. p>
Merci VonC pour la perspicacité,
Merci VonC pour la perspicacité, comme décrit ci-dessus, j'utilise plusieurs clés ssh et j'ai ajouté les entrées dans la configuration ssh. Lors du clonage en utilisant ces derniers, cela fonctionne très bien. Mais lorsque je pousse en tant que deuxième utilisateur, cela ne fonctionne que si j'utilise la commande mentionnée précédemment. J'ai également posé deux questions concernant l'utilisation des entrées du fichier de configuration. Voulez-vous dire aussi si je ne clone aucun dépôt en utilisant https, je ne devrais jamais avoir les informations d'identification par défaut que git essaie d'utiliser lors du push?
"Mais quand on pousse en tant que deuxième utilisateur, cela ne fonctionne que si j'utilise la commande mentionnée précédemment.": Cela fonctionnera si vous utilisez la bonne URL SSH, celle faisant référence à la bonne entrée dans la configuration ssh. Sans voir l'URL / syntaxe exacte utilisée pour l'URL d'origine distante, je ne peux pas déterminer pourquoi il ne parvient pas à utiliser la deuxième clé SSH utilisateur.
@Schwagmister "si je ne clone aucun dépôt en utilisant https, je ne devrais jamais avoir les informations d'identification par défaut que git essaie d'utiliser lors du push?": Cela signifierait utiliser SSH, et les informations d'identification ne sont pas nécessaires dans ce cas: la clé SSH privée est suffisante pour identifier toi.
Il utilise exactement le même format que l'utilisateur d'origine, mais je ne peux pas pousser à moins d'ajouter cette commande pour redéfinir le fichier d'identité à utiliser même s'il a été cloné en utilisant le même fichier d'identité. Je peux fournir des commandes exactes lorsque je suis à mon bureau et toutes les sorties dont vous avez besoin.
@Schwagmister Ce serait utile: je ne peux pas interpréter "Il utilise exactement le même format que l'utilisateur d'origine"
Donc, en termes généraux, j'ai deux entrées dans la configuration ssh qui prennent toutes les deux la forme Host [nouveau nom d'hôte] HostName github.com user git IdentityFile [chemin vers la clé privée]. De là, je clone les dépôts en utilisant ces entrées, git clone [new hostname]: [username] / [repo] .git. J'apporte quelques modifications, puis dans chaque dépôt respectif lorsque j'essaie de faire git push, je suis capable de pousser le dépôt cloné à partir du compte d'origine, mais dans le dépôt cloné à partir du deuxième utilisateur, je reçois un message disant que l'utilisateur d'origine ne le fait pas Je n'ai pas les permissions. Cela signifie qu'il essaie de pousser comme l'utilisateur d'origine que j'ai utilisé dans Git, n'est-ce pas?
Le deuxième dépôt a été cloné en utilisant le fichier d'identité de l'entrée respective dans la configuration ssh, mais quand je le pousse, il essaie d'utiliser l'utilisateur d'origine plutôt que le fichier d'identité avec lequel il a été cloné
@Schwagmister pas nécessairement: essayez ssh -T SecondNewHostname : GitHub vous dira qui vous êtes.
J'ai essayé et je ne me souviens pas du nom d'utilisateur qu'il a donné mais il a été authentifié avec succès, je jure que c'était le bon utilisateur. Mais là où ça échoue, c'est lors de la poussée. Je veux dire si je vérifie le .git / config de ce repo, il utilise le chemin correct, c'est-à-dire [nouveau nom d'hôte]: [nom d'utilisateur] / [repo] .git qui devrait utiliser le même fichier d'identité avec lequel il a été cloné, mais le message l'indique essaie de s'authentifier auprès de l'autre utilisateur.
@Schwagmister "J'ai essayé et je ne me souviens plus du nom d'utilisateur qu'il a donné mais il a été authentifié avec succès,": pouvez-vous réessayer?
@Schwagmister Encore une fois, sans voir la syntaxe spécifique utilisée, je ne peux pas être sûr de ce qui se passe ici.
Je viens de mettre à jour ma question avec tout Von, faites-moi savoir si vous avez besoin de plus.
Von, c'est ça, ce stupide fichier d'identité. J'ai copié la première entrée et j'ai oublié de changer le chemin. Merci de votre aide!
@Schwagmister Pas de problème. J'ai certainement ma juste part d'erreur de copier-coller;)
Peut-être que je me suis précipité et n'ai pas vérifié trois fois! Quoi qu'il en soit, j'apprécie vraiment l'aide!
D'après la conversation avec VonC, vous pouvez clairement voir dans le fichier de configuration ssh que le fichier d'identité du deuxième utilisateur était incorrect car il pointait vers le premier fichier d'utilisateurs. La deuxième entrée a été copiée à partir de la première et cette valeur n'a pas été modifiée.
Après avoir modifié la valeur pour pointer vers la clé correcte, c'est-à-dire ~ / .ssh / schwaggs_key, j'ai pu cloner et pousser sans problème. En remarque, je dois définir les propriétés de messagerie et de nom de l'utilisateur dans git pour chaque référentiel extrait de chaque utilisateur, c'est-à-dire une fois dans le dépôt,
git config user.email "github account email" git config user.name "github account username"
Ce que vous devez faire est de créer une nouvelle clé ssh pour votre deuxième compte Github car par défaut, git utilise la clé de votre premier compte Github et lorsque vous essayez de pousser à partir du deuxième compte, vous obtenez à distance: Permission to privateuser / privaterepo.git refusé à workuser. workeruser dans ce cas est le nom d'utilisateur de votre premier compte Github. Vous ne pouvez donc pas pousser vers votre deuxième compte Github en utilisant le nom d'utilisateur du premier compte Github. Suivez ce lien pour obtenir de l'aide.
Votre réponse est bonne, mais elle pourrait être améliorée en créant un lien vers les documents officiels de github, et pas seulement une vidéo YouTube.
Je peux répondre à cette partie: pourquoi cette clé n'est-elle pas déjà ciblée si elle a été clonée en utilisant ce même fichier d'identité? Parce que
gitne stocke pas la clé utilisée pour cloner. Vous devez le configurer vous-même soit en définissant la variable d'environnement$ GIT_SSH_COMMANDou en configurantgit config core.sshCommand" ssh -i " ou en manipulant les noms d'hôte.phd, cela a fini par être un mauvais chemin de fichier d'identité pour mon deuxième utilisateur dans le fichier de configuration ssh. Merci pour votre contribution!