Git push nécessite un nom d'utilisateur et un mot de passe

J'ai cloné un référentiel Git de mon compte GitHub vers mon PC.

Je veux travailler avec mon PC et mon ordinateur portable, mais avec un seul compte GitHub.

Lorsque j'essaie de pousser ou de tirer de GitHub à l'aide de mon PC, cela nécessite un nom d'utilisateur et un mot de passe, mais pas lorsque j'utilise l'ordinateur portable!

Je ne veux pas taper mon nom d'utilisateur et mon mot de passe chaque fois que j'interagis avec  origin. Qu'est-ce que j'oublie ici?

Une cause courante est le clonage utilisant la valeur par défaut (HTTPS) au lieu de SSH. Vous pouvez corriger cela en allant dans votre référentiel, en cliquant sur "Cloner ou télécharger", puis en cliquant sur le bouton "Utiliser SSH" au-dessus du champ URL et en mettant à jour l'URL de votre télécommande d'origine comme ceci:

git remote set-url origin [email protected]:username/repo.git

Ceci est documenté sur GitHub: Passer des URL distantes de HTTPS à SSH .

Authentification permanente avec les référentiels Git

Exécutez la commande suivante pour activer la mise en cache des informations d'identification :

$ git config credential.helper store
$ git push https://github.com/owner/repo.git

Username for 'https://github.com': <USERNAME>
Password for 'https://[email protected]': <PASSWORD>

Vous devez également spécifier l' expiration de la mise en cache ,

git config --global credential.helper 'cache --timeout 7200'

Après avoir activé la mise en cache des informations d'identification, il sera mis en cache pendant 7200 secondes (2 heures) .

Je viens de rencontrer le même problème, et la solution la plus simple que j'ai trouvée était d'utiliser l'URL SSH au lieu de HTTPS:

ssh://[email protected]/username/repo.git

Et pas ça:

https://github.com/username/repo.git

Vous pouvez maintenant valider avec juste la clé SSH au lieu de usernameet password.

En plus de passer à SSH, vous pouvez également continuer à utiliser HTTPS, si cela ne vous dérange pas de mettre votre mot de passe en texte clair. Mettez ceci dans votre ~/.netrcet il ne vous demandera pas votre nom d'utilisateur / mot de passe (au moins sur Linux et Mac):

machine github.com
       login <user>
       password <password>

Ajout (voir le deuxième commentaire de VonC): sous Windows, le nom du fichier est %HOME%\_netrc.

Lisez également le premier commentaire de VonC au cas où vous voudriez crypter.

Un autre ajout (voir le commentaire de user137717) que vous pouvez utiliser si vous avez Git 1.7.10 ou plus récent .

Cachez votre mot de passe GitHub dans Git en utilisant un assistant d'identification :

Si vous clonez des référentiels GitHub à l'aide de HTTPS, vous pouvez utiliser un assistant d'identification pour dire à Git de se souvenir de votre nom d'utilisateur et de votre mot de passe GitHub chaque fois qu'il communique avec GitHub.

Cela fonctionne également sur Linux, Mac et Windows.

Pour les non initiés qui sont confus par les réponses précédentes, vous pouvez faire:

git remote -v

Qui répondra avec quelque chose comme

origin    https://[email protected]/yourname/yourrepo.git (fetch)
origin    https://[email protected]/yourname/yourrepo.git (push)

Ensuite, vous pouvez exécuter la commande que beaucoup d'autres ont suggérée, mais maintenant vous connaissez votre nom et votre référence d'en haut, vous pouvez donc simplement couper et coller yourname/yourrepo.gitde ce qui précède dans:

git remote set-url origin [email protected]:yourname/yourrepo.git

Si vous utilisez SSH et votre clé privée est cryptée avec un mot de passe, alors vous serez toujours invité à entrer le mot de passe / mot de passe pour la clé privée lorsque vous effectuez des opérations de réseau avec Git comme push, pullet fetch.

Utilisez ssh-agent pour enregistrer les informations d'identification de mot de passe / mot de passe de clé privée

Si vous voulez éviter d'avoir à saisir votre mot de passe à chaque fois, vous pouvez utiliser ssh-agentpour stocker vos informations d'identification de mot de passe de clé privée une fois par session de terminal, comme je l'explique dans ma réponse à Impossible d'ouvrir une connexion avec votre agent d'authentification :

$ eval `ssh-agent -s`
$ ssh-add

Dans un Bash msysgit Windows, vous devez évaluer la sortie de ssh-agent, mais je ne sais pas si vous devez faire de même dans d'autres environnements de développement et systèmes d'exploitation.

ssh-addrecherche une clé privée dans votre .sshdossier de départ appelée id_rsa, qui est le nom par défaut, mais vous pouvez passer un chemin de fichier à une clé avec un nom différent.

Tuer l'agent

Lorsque vous avez terminé votre session de terminal, vous pouvez arrêter ssh-agentavec le drapeau d' arrêt -k:

$ ssh-agent -k

Comme expliqué dans le ssh-agentmanuel :

-k

Tuez l'agent actuel (donné par la variable d'environnement SSH_AGENT_PID).

Délai d'expiration facultatif

En outre, il peut prendre un paramètre de délai d'expiration facultatif comme ceci:

$ ssh-add -t <timeout>

où <timeout>est le format <n>hdes <n>heures, <n>mpour <n>minutes, et ainsi de suite.

Selon le ssh-agentmanuel :

-t life

Définissez une valeur par défaut pour la durée de vie maximale des identités ajoutées à l'agent. La durée de vie peut être spécifiée en secondes ou dans un format d'heure spécifié dans sshd_config (5) . Une durée de vie spécifiée pour une identité avec ssh-add (1) remplace cette valeur. Sans cette option, la durée de vie maximale par défaut est indéfiniment.

Voir cette page pour plus de formats d'heure .

Avertissement de sécurité pour les utilisateurs de Cygwin

Les utilisateurs de Cygwin doivent être conscients d'un risque potentiel de sécurité lié à l'utilisation de ssh-agent dans Cygwin :

les gens devraient être conscients des dangers potentiels de ssh-agent sous Cygwin 1 , bien que sous un netstat local et un scan de port distant, il ne semble pas que le port spécifié dans / tmp / ssh-foo soit accessible à tous ...?

[1]: http://www.cygwin.com/ml/cygwin/2001-01/msg00063.html

Et au lien cité :

cependant, notez que les sockets de domaine Unix de Cygwin sont FONDAMENTALEMENT INSÉCURES et donc je DÉCOURAGE fortement l' utilisation de ssh-agent sous Cygwin.

lorsque vous exécutez ssh-agent sous Cygwin, il crée un socket AF_UNIX dans le /tmp/ssh-$USERNAME/répertoire. Sous Cygwin, les sockets AF_UNIX sont émulés via les sockets AF_INET. Vous pouvez facilement voir cela si vous regardez un /tmp/ssh-$USERNAME/agent-socket-*fichier via le Bloc-notes. Vous verrez quelque chose comme

!<socket >2080

alors cours netstat -aet surprends! Vous avez un programme qui écoute le port 2080. C'est ssh-agent. Lorsque ssh reçoit un défi RSA du serveur, il fait référence au correspondant /tmp/ssh-$USERNAME/agent-socket-*(sous Cygwin, dans notre cas, cela signifie qu'il ouvrira la connexion localhost:2080) et demande à ssh-agent de traiter le défi RSA avec la clé privée qu'il possède, puis il transmet simplement la réponse reçue de l'agent ssh au serveur.

Sous Unix, un tel scénario fonctionne sans problème, car le noyau Unix vérifie les autorisations lorsque le programme essaie d'accéder à un socket AF_UNIX. Pour les sockets AF_INET, cependant, les connexions sont anonymes (lire "non sécurisé"). Imaginez que vous ayez l'agent ssh Cygwin en cours d'exécution. Un pirate malveillant peut analyser votre box, localiser le port ouvert utilisé par ssh-agent, ouvrir une connexion à votre serveur SSH, en recevoir le défi RSA, l'envoyer à votre ssh-agent via un port ouvert qu'il a trouvé, recevoir le Réponse RSA, envoyez-la au serveur SSH et le tour est joué, il / elle s'est connecté avec succès à votre serveur comme vous.

Source: Configurer Git

La commande suivante enregistrera votre mot de passe en mémoire pendant un certain temps (pour Git 1.7.10 ou plus récent).

$ git config --global credential.helper cache
# Set git to use the credential memory cache

$ git config --global credential.helper 'cache --timeout=3600'
# Set the cache to timeout after one hour (setting is in seconds)

Lorsque vous utilisez https pour Git pull & push, configurez simplement remote.origin.urlvotre projet pour éviter de saisir un nom d'utilisateur (ou / et un mot de passe) chaque fois que vous appuyez.

Comment configurer remote.origin.url:

Format URL:
    https: // {nom d'utilisateur: mot de passe @} github.com/ {propriétaire} / {repo}

Paramètres dans l'URL:

* nom d'utilisateur 

    Facultatif, le nom d'utilisateur à utiliser en cas de besoin. 
authentification,
    si spécifié, pas besoin de saisir à nouveau le nom d'utilisateur lorsque vous avez besoin d'une authentification.
    N'utilisez pas de courrier électronique; utilisez votre nom d'utilisateur sans "@", sinon l'URL ne peut pas être analysée correctement,
* mot de passe
    facultatif, le mot de passe à utiliser lorsque vous avez besoin d'une authentification.
    S'il est spécifié, il n'est pas nécessaire de saisir à nouveau le mot de passe lorsque vous avez besoin d'une authentification.
    Pointe:
        cette valeur est stockée en texte brut, donc pour des raisons de sécurité, ne spécifiez pas ce paramètre,
*

par exemple
    git config remote.origin.url https: //[email protected]/eric/myproject

@Update - utilisation ssh

Je pense que l'utilisation du sshprotocole est une meilleure solution que https, même si l'étape de configuration est un peu plus complexe.

Étapes approximatives:

• Créer des clés ssh à l'aide d'une commande, par exemple ssh-keygensous Linux, sur Windows, msysgitfournir des commandes similaires.
• Conservez la clé privée sur l'ordinateur local à un emplacement approprié, par exemple ~/.ssh. Et ajoutez-le à l'agent ssh via la ssh-addcommande.
• Téléchargez la clé publique sur le serveur Git.
• Changement remote.origin.urldu référentiel Git en sshstyle, par exemple,[email protected]:myaccount/myrepo.git
• Ensuite, lorsque vous tirez ou poussez, il n'est jamais nécessaire d'entrer le nom d'utilisateur ou le mot de passe.

Conseils:

• Si votre clé ssh a une phrase secrète, vous devez la saisir lors de la première utilisation de la clé après chaque redémarrage de votre machine, par défaut.

@Update - Bascule entre httpset sshprotocole.

Un simple changement remote.origin.urlsuffira, ou vous pouvez éditer repo_home/.git/configdirectement pour changer la valeur (par exemple en utilisant visous Linux).

Habituellement, j'ajoute une ligne pour chaque protocole et commente l'un d'eux en utilisant #.

Par exemple

[origine "distante]
        url = [email protected]: myaccount / myrepo.git
        # url = https: //[email protected]/myaccount/myrepo.git
        chercher = + refs / têtes / *: refs / télécommandes / origine / *

Vous pouvez mettre en cache votre mot de passe GitHub dans Git:

Suivez simplement les instructions de la documentation officielle de GitHub .

Après avoir suivi les instructions du lien ci-dessus, vous devriez pouvoir pousser / tirer vers / depuis votre référentiel sans taper à chaque fois votre nom d'utilisateur / mot de passe.

Voici une autre option:

Au lieu d'écrire

git push origin HEAD

Vous pourriez écrire:

git push https://user:[email protected]/path HEAD

Évidemment, avec la plupart des shells, cela entraînera la mise en cache du mot de passe dans l'historique, alors gardez cela à l'esprit.

Ce qui a fonctionné pour moi, c'est d'éditer .git/configet d'utiliser

[remote "origin"]
        url = https://<login>:<password>@gitlab.com(...).git

Il va sans dire que c'est un moyen non sécurisé de stocker votre mot de passe, mais il existe des environnements / cas où cela peut ne pas être un problème.

Si la clé ou le .netrcfichier SSH ne fonctionnait pas pour vous, alors une autre solution simple, mais moins sécurisée, qui pourrait fonctionner pour vous est git-credential-store - Aide pour stocker les informations d'identification sur le disque:

git config --global credential.helper store

Par défaut, les informations d'identification seront enregistrées dans un fichier ~/.git-credentials. Il sera créé et écrit dans.

Veuillez noter que l'utilisation de cette aide stockera vos mots de passe non chiffrés sur le disque, protégés uniquement par les autorisations du système de fichiers. Si cela peut ne pas être un compromis de sécurité acceptable.

J'ai eu le même problème.

J'ai donc changé le .git/configfichier de mon projet,

url = https://github.com/<your-user-here>/<your-repo-here>

à

url = [email protected]:<your-user-here>/<your-repo-here>

et ajouté la clé publique SSH au profil Git qui est en cours de configuration.

Pour la clé publique SSH:

cat ~/.ssh/id_rsa.pub

Mise à jour pour HTTPS:

GitHub a lancé un nouveau programme pour Windows qui stocke vos informations d'identification lorsque vous utilisez HTTPS:

Utiliser:

• Téléchargez le programme ici

• Une fois que vous exécutez le programme, il modifiera votre .gitconfigfichier. Vérifiez à nouveau s'il a édité le bon .gitconfigau cas où vous en auriez plusieurs. S'il n'a pas modifié le bon, ajoutez ce qui suit à votre.gitconfig

  [credential]
      helper = !'C:\\Path\\To\\Your\\Downloaded\\File\\git-credential-winstore.exe'
  

  REMARQUE le saut de ligne après [credential]. C'est requis.

• Ouvrez votre client de ligne de commande et essayez git push origin masterune fois. S'il vous demande un mot de passe, entrez-le et vous avez terminé. Mot de passe enregistré!

Pour les utilisateurs de Windows Git, après l'exécution git config --global credential.helper store, s'il demande toujours un mot de passe, vous feriez mieux de vérifier où le fichier de configuration est écrit, en utilisant cette commande

git config --list --show-origin

Dans mon cas, après avoir modifié manuellement le fichier de configuration «C: \ Program Files \ Git \ mingw64 \ etc \ gitconfig» et ajouté le texte suivant, cela a fonctionné.

[credential]
    helper = store

Vous avez essentiellement deux options.

Si vous utilisez le même utilisateur sur les deux machines, vous devez copier la clé .pub sur votre PC, donc GitHub sait que vous êtes le même utilisateur.

Si vous avez créé un nouveau fichier .pub pour votre PC et que vous souhaitez traiter les machines comme des utilisateurs différents, vous devez enregistrer le nouveau fichier .pub sur le site Web de GitHub.

Si cela ne fonctionne toujours pas, cela peut être dû au fait que ssh n'est pas configuré correctement et que ssh ne parvient pas à trouver l'emplacement de vos clés. Essayer

ssh -vv [email protected]

Pour obtenir plus d'informations sur les raisons de l'échec de SSH.

Mise à jour directe de votre fichier de configuration Git ( si vous ne souhaitez pas mémoriser de fantastiques commandes ):

Ouvrez votre .git/configfichier dans votre éditeur de texte préféré. Ce sera dans le dossier que vous avez cloné ou dans le référentiel dans lequel vous avez joué git init. Allez dans ce référentiel. .gitest un dossier caché, et en appuyant sur Ctrl+ Hdevrait afficher le dossier caché, ( ls -adans le terminal).

Voici un exemple du .git/configfichier. Copiez et collez ces lignes et assurez-vous de mettre à jour ces lignes avec vos informations Git.

[user]
        name = Tux
        email = [email protected]
        username = happy_feet

[remote "origin"]
        url = https://github.com/happy_feet/my_code.git
        fetch = +refs/heads/*:refs/remotes/origin/*

Modifiez la partie URL avec le format suivant pour SSH:

url = [email protected]:happy_feet/my_code.git

( Les formats ci-dessus ne changent pas avec divers serveurs distants Git comme GitHub ou Bitbucket. C'est la même chose si vous utilisez Git pour le contrôle de version ):

Remarque: La façon SSH de se connecter à un référentiel Git distant vous obligera à ajouter votre clé SSH publique à votre serveur distant Git ( comme GitHub ou Bitbucket. Recherchez la page des paramètres pour les clés SSH ).

Pour savoir comment générer vos clés SSH, reportez-vous à: Création de clés SSH

C'est ce qui a fonctionné pour moi:

git remote set-url origin https://[email protected]/username/reponame.git

Exemple:

git remote set-url origin https://[email protected]/jsmith/master.git

Vous devez effectuer deux étapes -

1. git remote remove origin
2. git remote add origin [email protected]:NuggetAI/nugget.git

Notez que l'URL Git est une URL SSH et non une URL HTTPS ... que vous pouvez sélectionner ici:

Si vous avez cloné HTTPS au lieu de SSH et que vous rencontrez un problème avec l'invite de nom d'utilisateur et de mot de passe lors de l'extraction, de la poussée et de la récupération. Vous pouvez résoudre ce problème simplement pour UBUNTU

Étape 1: déplacer vers le répertoire racine

cd ~/

créer un fichier .git-credentials

Ajoutez ce contenu à ce fichier avec vous usename passwordetgithosting URL

https://user:[email protected]

Exécutez ensuite la commande

git config --global credential.helper store

Maintenant, vous pourrez tirer et récupérer tous les détails de votre repo sans tracas.

Si vous utilisez Git (par exemple, Git Bash) sous Windows (et si vous ne souhaitez pas passer de HTTPS à SSH), vous pouvez également utiliser Git Credential Manager pour Windows

Cette application gardera pour vous le nom d'utilisateur et le mot de passe ...

Comme de nombreux utilisateurs l'ont dit, il vous suffit de changer l'URL de votre référentiel Git de HTTPS en SSH.

Si vous n'avez pas généré de clé SSH sur votre machine, vous devrez le faire.

Juste comme information supplémentaire, après avoir fait ce changement, j'obtenais toujours la même erreur:

Permission refusée.

Dans mon cas, le problème était que j'utilisais le shell Windows pour exécuter la commande ngh; puisque cette commande devrait ouvrir une invite pour demander la phrase SSH et que Windows Shell n'ouvre pas ce type d'invites, l'authentification a simplement échoué.

Donc, je devais juste ouvrir le shell Git et y exécuter la commande ngh, mettre la phrase SSH à l'invite à chaque fois qu'elle le demandait et "voilà" ... Ça fonctionnait bien!

    # create the company identity file
    ssh-keygen -t rsa -b 4096 -C "[email protected]"
    # save private key to ~/.ssh/id_rsa.corp, 
    cat ~/.ssh/id_rsa.corp.pub # copy paste this string into your corp web ui security ssh keys

    # create your private identify file
    ssh-keygen -t rsa -b 4096 -C "[email protected]"
    # save private key to ~/.ssh/id_rsa.me, note the public key ~/.ssh/id_rsa.me.pub
    cat ~/.ssh/id_rsa.me.pub # copy paste this one into your githubs, private keys

    # clone company internal repo as follows
    GIT_SSH_COMMAND="ssh -i ~/.ssh/id_rsa.corp -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" \
    git clone [email protected]:corp/project.git

    export git_msg="my commit msg with my corporate identity"
    git add --all ; git commit -m "$git_msg" --author "MeFirst MeLast <[email protected]>"
    GIT_SSH_COMMAND="ssh -i ~/.ssh/id_rsa.corp -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" \
    git push 

    # clone public repo as follows
    GIT_SSH_COMMAND="ssh -i ~/.ssh/id_rsa.corp -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" \
    git clone [email protected]:acoolprojectowner/coolproject.git

    export git_msg="my commit msg with my personal identity"
    git add --all ; git commit -m "$git_msg" --author "MeFirst MeLast <[email protected]>"
    GIT_SSH_COMMAND="ssh -i ~/.ssh/id_rsa.me -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" \
    git push 

    # stop :: how-to use different ssh identity files

Si vous avez activé 2FA sur votre compte Github, votre mot de passe normal ne fonctionnera pas à cette fin, mais vous pouvez générer un jeton d'accès personnel et l'utiliser à sa place.

Visitez la page Settings-> Developer Settings-> Personal Access Tokensdans GitHub ( https://github.com/settings/tokens/new ), et générez un nouveau Token avec toutes les autorisations Repo :

La page affichera alors la nouvelle valeur de jeton. Enregistrez cette valeur et utilisez-la à la place de votre mot de passe lorsque vous accédez à votre référentiel sur GitHub:

> git push origin develop
Username for 'https://github.com': <your username>
Password for 'https://<your username>@github.com': <your personal access token>