Comment fournir un nom d'utilisateur et un mot de passe lors de l'exécution de «git clone git@remote.git»?


847

Je sais comment fournir un nom d'utilisateur et un mot de passe à une demande HTTPS comme celle-ci:

git clone https://username:password@remote

Mais j'aimerais savoir comment fournir un nom d'utilisateur et un mot de passe à la télécommande comme ceci:

git clone git@remote.git

J'ai essayé comme ça:

git clone username:password@git@remote.git
git clone git@username:password@remote.git
git clone git@remote.git@username:password

Mais ils n'ont pas fonctionné.


4
Tu ne peux pas. Le "git" devant le "@" est déjà un nom d'utilisateur. D'où avez-vous obtenu l'URL du référentiel (git@remote.get)? D'où vous est venue l'idée que vous deviez fournir un nom d'utilisateur et un mot de passe différents?
Ken Thomases

3
Mon URL de dépôt provient de heroku "git@heroku.com: zxy-helloworld.git". Et j'utilise le shell emacs pour cloner et pousser. Si le shell demande un mot de passe, emacs se bloquera. Il s'agit d'un problème connu avec emacs sous Windows: gnu.org/software/emacs/windows/…
coordonne le

Que faire si le nom d'utilisateur est un e-mail? comment le tapez-vous? myemail @ gmail.com @ example.com ?
Kyon Perez

Réponses:


1319

D'après le commentaire de Michael Scharf:

Vous pouvez omettre le mot de passe pour qu'il ne soit pas enregistré dans votre fichier d'historique Bash:

git clone https://username@github.com/username/repository.git

Il vous demandera votre mot de passe.

Alternativement, vous pouvez utiliser:

git clone https://username:password@github.com/username/repository.git

Cette méthode a fonctionné pour moi à partir d'un référentiel GitHub.


5
cela ne doit pas être la même chose d'ailleurs. Si votre collègue a créé le dépôt git et que vous vous connectez sous un autre compte, ce ne sera pas le même.
holgac

49
Il n'est pas conseillé de mettre le mot de passe dans l'URL car ce fichier est enregistré sur le .git / config. N'est pas sûr, il est préférable d'utiliser la clé ssh
zetanova

55
@MrDuk aucun problème, échappez-vous (comme% 40 iirc).
Benjamin Gruenbaum

57
Vous pouvez laisser le mot de passe: git clone https://username@github.com/username/repository.git. git vous le demandera et il ne sera pas enregistré dans .git / config ni dans votre historique bash
Michael_Scharf

37
vous pouvez également taper 'espace' au début de la ligne afin que linux ne stocke pas la commande dans l'historique
Nicolas Zozol

213

Le user@host:path/to/repoformat indique à Git d'utiliser ssh pour se connecter hostavec un nom d'utilisateur user. De git help clone:

Une autre syntaxe de type scp peut également être utilisée avec le protocole ssh:

[user@]host.xz:path/to/repo.git/

La partie avant le @est le nom d'utilisateur, et la méthode d'authentification (mot de passe, clé publique, etc.) est déterminée par ssh, pas Git. Git n'a aucun moyen de transmettre un mot de passe à ssh, car ssh peut même ne pas utiliser de mot de passe selon la configuration du serveur distant.

Utilisez ssh-agentpour éviter de taper des mots de passe tout le temps

Si vous ne voulez pas taper votre mot de passe ssh tout le temps, la solution typique consiste à générer une paire de clés publique / privée , à mettre la clé publique dans votre ~/.ssh/authorized_keysfichier sur le serveur distant et à charger votre clé privée dans ssh-agent. Voir également Configurer Git sur SSH pour se connecter une fois , la page d'aide de GitHub sur les phrases secrètes des clés ssh , la documentation ssh de gitolite et la documentation des clés ssh de Heroku .

Choisir entre plusieurs comptes sur GitHub (ou Heroku ou ...)

Si vous avez plusieurs comptes à un endroit comme GitHub ou Heroku, vous aurez plusieurs clés ssh (au moins un par compte). Pour choisir le compte sous lequel vous souhaitez vous connecter, vous devez indiquer à ssh quelle clé privée utiliser .

Par exemple, supposons que vous disposiez de deux comptes GitHub: fooet bar. Votre clé ssh pour foois ~/.ssh/foo_github_idet votre clé ssh for baris ~/.ssh/bar_github_id. Vous souhaitez accéder git@github.com:foo/foo.gitavec votre foocompte et git@github.com:bar/bar.gitavec votre barcompte. Vous ajouteriez ce qui suit à votre ~/.ssh/config:

Host gh-foo
    Hostname github.com
    User git
    IdentityFile ~/.ssh/foo_github_id
Host gh-bar
    Hostname github.com
    User git
    IdentityFile ~/.ssh/bar_github_id

Vous devez ensuite cloner les deux référentiels comme suit:

git clone gh-foo:foo/foo.git  # logs in with account foo
git clone gh-bar:bar/bar.git  # logs in with account bar

Éviter complètement ssh

Certains services offrent un accès HTTP comme alternative à ssh:

  • GitHub:

    https://username:password@github.com/username/repository.git
    
  • Gitorious:

    https://username:password@gitorious.org/project/repository.git
    
  • Heroku: Voir cet article de support .

AVERTISSEMENT : l'ajout de votre mot de passe à l'URL du clone obligera Git à stocker votre mot de passe en texte brut dans .git/config. Pour stocker en toute sécurité votre mot de passe lorsque vous utilisez HTTP, utilisez un assistant d'identification. Par exemple:

git config --global credential.helper cache
git config --global credential.https://github.com.username foo
git clone https://github.com/foo/repository.git

Ce qui précède amènera Git à demander votre mot de passe toutes les 15 minutes (par défaut). Voir git help credentialspour plus de détails.


C'est la meilleure explication du fonctionnement de git avec SSH. Ma compréhension est que lorsque vous spécifiez git@githost.com: chemin / vers / repo.git, cela indique effectivement à git que l'utilisateur est lui-même git et qu'il devrait aller récupérer vos informations d'identification (clé publique) auprès de l'agent ssh pour le Hébergez "githost.com".
Anael

39

Dans les commentaires de la réponse de @ Bassetassen , @plosco a mentionné que vous pouvez au moins utiliser git clone https://<token>@github.com/username/repository.gitpour cloner à partir de GitHub. Je pensais que je développerais la façon de procéder, au cas où quelqu'un trouverait cette réponse comme je l'ai fait en essayant d'automatiser un clonage.

GitHub a un guide très pratique sur la façon de le faire, mais il ne couvre pas ce qu'il faut faire si vous souhaitez tout inclure sur une seule ligne à des fins d'automatisation. Il avertit que l' ajout du jeton à l'URL du clone le stockera en texte brut dans .git/config . C'est évidemment un risque de sécurité pour presque tous les cas d'utilisation, mais comme je prévois de supprimer le dépôt et de révoquer le jeton lorsque j'aurai terminé, je m'en fiche.

1. Créez un jeton

GitHub a un guide complet ici sur la façon d'obtenir un jeton, mais voici le TL; DR.

  1. Accédez à Paramètres> Paramètres développeur> Jetons d'accès personnels ( voici un lien direct )
  2. Cliquez sur "Générer un nouveau jeton" et entrez à nouveau votre mot de passe. ( voici un autre lien direct )
  3. Définissez une description / un nom pour cela, vérifiez l'autorisation "repo" et cliquez sur le bouton "Générer un jeton" en bas de la page.
  4. Copiez votre nouveau jeton avant de quitter la page

2. Clonez le référentiel

Identique à la commande que @plosco a donnée,, git clone https://<token>@github.com/<username>/<repository>.gitremplacez simplement <token>, <username>et <repository>par toutes vos informations.

Si vous voulez le cloner dans un dossier spécifique, insérez simplement l'adresse du dossier à la fin comme ceci:, git clone https://<token>@github.com/<username>/<repository.git> <folder><folder>est, vous l'avez deviné, le dossier dans lequel le cloner! Vous pouvez bien sûr utiliser ., .., ~, etc. ici comme vous pouvez ailleurs.

3. Ne laisser aucune trace

Tout cela peut ne pas être nécessaire, selon la sensibilité de ce que vous faites.

  • Vous ne voudrez probablement pas laisser ce jeton traîner si vous n'avez pas l'intention de l'utiliser pendant un certain temps, alors revenez à la page des jetons et appuyez sur le bouton Supprimer à côté.
  • Si vous n'avez plus besoin du dépôt, supprimez-le rm -rf <folder>.
  • Si vous avez à nouveau besoin du dépôt, mais n'avez pas besoin de l'automatiser à nouveau, vous pouvez supprimer la télécommande en faisant git remote remove originou simplement supprimer le jeton en exécutant git remote set-url origin https://github.com/<username>/<repository.git>.
  • Effacez votre historique bash pour vous assurer que le jeton n'y reste pas connecté. Il existe de nombreuses façons de le faire, voir cette question et cette question . Cependant, il peut être plus facile de simplement ajouter toutes les commandes ci-dessus avec un espace afin d'éviter qu'elles ne soient stockées au départ.

Notez que je ne suis pas un pro, donc ce qui précède peut ne pas être sécurisé dans le sens où aucune trace ne serait laissée pour une sorte de travail médico-légal.


1
https://<token>@github.comn'a pas été acceptée avec mon portail, j'ai dû utiliserhttps://oauth2:<token>@github.com
MushyPeas

25

Bien qu'il existe de nombreuses réponses, je suis confronté au problème répété lorsque le nom d'utilisateur ou le mot de passe contient des caractères spéciaux.

L'URL code votre nom d'utilisateur et votre mot de passe pour git, puis les utilise dans le cadre de l'URL elle-même (lorsqu'il n'y a aucun problème de sécurité).

Dites, valeur encodée URL du nom d'utilisateur

'utilisateur + 1' est l'utilisateur% 2B1

et valeur codée URL du mot de passe

'Welcome @ 1234' est Welcome% 401234

L'URL de votre clone GIT ressemblerait alors à:

git clone https://user%2B1:Welcome%401234@actual-git-url-for-the-repo fonctionne parfaitement, alors que,

git clone https: // user + 1: Welcome @ 1234 @ actual-git-url-for-the-repo vous donne 403 erreurs

J'espère que cela t'aides.

Au cas où, vous voulez encoder l'URL en ligne: https://www.urlencoder.org/


13

J'ai résolu ce problème de la manière suivante:

entrez la description de l'image ici


11
jamais une bonne idée de taper votre mot de passe en ligne de commande. Saviez-vous que votre système peut stocker l'historique de la ligne de commande dans un fichier? (Ex: Linux a un fichier caché nommé .bash_history)
augusto

Correct. Chaque fois que je fais cela, ou quelque chose comme ça, ce qui peut parfois être très pratique, je supprime toujours la commande que j'ai utilisée de l'historique (history -d).
Francesco Marchetti-Stasi

4
@ FrancescoMarchetti-Stasi vous n'avez pas besoin de supprimer la commande, utilisez simplement un espace au début de la commande et il ne sera jamais stocké dans l'historique.
Ishtiyaq Husain

Oui - je l'ai appris il y a seulement quelques mois, après presque 30 ans sur les systèmes Unix ... honte à moi :)
Francesco Marchetti-Stasi

9

Sous Windows , les étapes suivantes doivent déclencher à nouveau la fenêtre de connexion GitHub lors de l' git cloneing:

  • Rechercher dans le menu de démarrage de "Credential Manager"
  • Sélectionnez "Informations d'identification Windows"
  • Supprimer toutes les informations d'identification liées à Git ou GitHub

résultat


8

Suivez ces arguments pour remplacer par vos cas spéciaux s'ils créent un problème:

! # $ & '() * +, /:; =? @ []

% 21% 23% 24% 26% 27% 28% 29% 2A% 2B% 2C% 2F% 3A% 3B% 3D% 3F% 40% 5B% 5D

Ainsi, par exemple-

URL réelle: https: // usern @ me: p @ ssword @ git / reponame.git

URL de la solution à utiliser: https: // usern% 40me: p%40ssword@git/reponame.git


C'était le problème exact que je cherchais et la réponse a très bien fonctionné. Merci beaucoup.
invinciblemuffi Il y a

5
git config --global core.askpass

Exécutez-le d'abord avant de cloner de la même manière, devrait être corrigé!


3
J'ai essayé celui-là, je ne le demande toujours pas.
Maarten Kieft

Définir une configuration globale n'est jamais une bonne idée car cela pourrait gâcher d'autres clones.
Martin

1

C'est une excellente question sur le débordement de pile, et les réponses ont été très instructives, de sorte que j'ai pu résoudre un problème ennuyeux que j'ai rencontré récemment.

L'organisation pour laquelle je travaille utilise le Atlassian's BitBucketproduit (pas Github), essentiellement leur version de GitHub afin que les référentiels puissent être sécurisés complètement sur site. Je rencontrais un problème similaire à @coordinate, en ce sens que mon mot de passe était requis pour un nouveau référentiel que j'ai extrait. Mes informations d'identification avaient été enregistrées globalement pour tous les BitBucketprojets, donc je ne sais pas ce qui a provoqué la perte des informations d'identification.

En bref, j'ai pu entrer la commande GIT suivante (en fournissant uniquement mon nom d'utilisateur), qui a ensuite invité le gestionnaire d'informations d'identification de Git à me demander le mot de passe, que j'ai ensuite pu enregistrer.

git clone https://user@code.domain.org/git/[organization]/[team]/[repository.git]

REMARQUE: les sous-chemins de répertoire entre crochets se réfèrent simplement à des références internes et varieront pour vous!


0

Si vous utilisez http/httpset que vous cherchez à AUTOMATIQUER ENTIÈREMENT le processus sans nécessiter aucune entrée utilisateur ou aucune invite utilisateur (par exemple: dans un pipeline CI / CD), vous pouvez utiliser l'approche suivante en tirant partigit credential.helper

GIT_CREDS_PATH="/my/random/path/to/a/git/creds/file"
# Or you may choose to not specify GIT_CREDS_PATH at all.
# See https://git-scm.com/docs/git-credential-store#FILES for the defaults used

git config --global credential.helper "store --file ${GIT_CREDS_PATH}"
echo "https://alice:${ALICE_GITHUB_PASSWORD}@github.com" > ${GIT_CREDS_PATH}

où vous pouvez choisir de définir la ALICE_GITHUB_PASSWORDvariable d'environnement à partir d'une commande shell précédente ou de votre configuration de pipeline, etc.

Rappelez-vous que git-credential-helper basé sur "store" stocke les mots de passe et les valeurs en texte brut. Assurez-vous donc que votre token / mot de passe dispose d'autorisations très limitées.


Maintenant, utilisez simplement https: //alice@github.com/my_repo.git partout où votre système automatisé doit récupérer le dépôt - il utilisera les informations d'identification pour alicein github.comas store par git-credential-helper.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.