Impossible de cloner un dépôt github sur Linux via HTTPS


87

J'essaie de faire un simple git clone https://github.com/org/project.gitsur une boîte CentOS mais obtenez:

erreur: l'URL demandée a renvoyé l'erreur: 401 lors de l'accès à https://github.com/org/project.git/info/refs

fatal: échec de la requête HTTP

Il ne me demande jamais mon nom d'utilisateur / mot de passe, échoue simplement.

Je peux passer exactement le même appel sur mon Mac sans problème.


C'est une nouvelle boîte CentOS 6.3 grande ouverte sur le cloud - l'accès Internet n'est pas un problème
Yarin

@Yarin: J'espère que vous avez déjà lu ceci: help.github.com/articles/https-cloning-errors Le dernier recours serait d'utiliser ssh je pense. En outre, vous voudrez peut-être vérifier l'e-mail avec lequel votre git est configuré ... pas sûr si cela aide mais assurez-vous qu'il correspond à celui que vous utilisez avec votre compte github.
greg0ire

ouais - aucun de ceux-ci ne vérifie - copie littéralement une commande de travail de mon terminal mac dans le terminal linux - pas d'invite de mot de passe, juste craps
Yarin

Réponses:


210

La réponse était simple mais pas évidente:

Au lieu de:

git clone https://github.com/org/project.git

faire:

git clone https://username@github.com/org/project.git

ou (non sécurisé)

git clone https://username:password@github.com/org/project.git

(Notez que dans le dernier cas, votre mot de passe pourra être visible par d'autres utilisateurs sur votre machine en exécutant ps u -u $youet apparaîtra en clair dans l'historique de votre shell par défaut)

Les 3 méthodes fonctionnent sur mon Mac, mais seules les 2 dernières fonctionnent sur le boîtier Linux distant. (En y repensant, c'est probablement parce que j'avais un nom d'utilisateur git global configuré sur mon Mac, alors que sur la télécommande je ne l'ai pas fait? Cela aurait pu être le cas, mais le manque d'invite pour un nom d'utilisateur m'a fait trébucher ... .)

Je n'ai vu cela documenté nulle part, alors le voici.


3
Merci d'avoir mentionné le git config --global user.namedétail, c'était tout pour moi!
GermanK

Notez qu'à partir de git 1.7.10, vous serez invité à entrer un nom d'utilisateur, selon @JERC , donc cela ne devrait plus être un problème ..
Yarin

J'ai eu le même problème (avec GIT 1.7.1, CentOS5), mais je ne pouvais pas ajouter le nom d'utilisateur / pwd dans l'URL car je devais installer des bundles à partir de dépôts privés Bitbucket (et évidemment je n'ajouterai pas de nom d'utilisateur et pw info dans un composer.json / composer.lock). Becouse GIT ne m'a pas permis de les taper manuellement, j'ai dû aller à la dure et j'ai mis à jour GIT avec l'aide du référentiel RPM Forge ( guru4hp.blogspot.hu/2012/08/… ). J'ai suivi le guide de @muness trouvé ici: serverfault.com/questions/448814/…
hattila

2
C'est la réponse si vous utilisez git 1.7.1 sur linux
Louie Miranda

1
applicable si vous utilisez quelque chose avant le 1.7.10
Amit G

32

Vous pouvez désactiver manuellement ssl verfiy et réessayer. :)

git config --global http.sslverify false

3
Pour le BeagleBone Black avec Angstrom, opkg ne fournit pas la version requise pour effectuer la vérification SSL, c'est donc le seul choix que j'ai trouvé pour fonctionner.
Josiah

1
L'instruction @flickerfly est valide..aucune autre façon de cloner en utilisant https sauf en utilisant cette méthode lors de l'utilisation de beaglebone black avec Angstrom OS.
Funky81

1
Fonctionne sur Centos. Merci.
030 le

La désactivation de la vérification SSL est un peu dangereuse. Un man-in-the-middle malveillant pourrait théoriquement vous envoyer un dépôt git modifié.
Mark Doliner

A également dû faire cela lors de l'utilisation de GitLab
Gerard

12

Assurez-vous que vous avez git 1.7.10 ou une version ultérieure, il demande maintenant correctement l'utilisateur / le mot de passe. (Vous pouvez télécharger la dernière version ici )


4
J'ai eu le même problème, ma version git était 1.7.1 lorsque je mets à niveau vers 1.7.10 maintenant Il invite l'utilisateur / mot de passe correctement !!, (la version 1.7.1 N'EST PAS LA MÊME À 1.7.10) Veuillez vérifier les versions avant à consacré.
JERC

10

J'ai dû spécifier le nom d'utilisateur pour travailler sur la version 1.7.1 de git:

git remote set-url origin https://username@github.com/org/project.git

10

J'ai rencontré le même problème, le message d'erreur et les informations sur le système d'exploitation sont les suivants

Informations sur le système d'exploitation:

CentOS version 6.5 (finale)

Linux 192-168-30-213 2.6.32-431.el6.x86_64 # 1 SMP ven 22 novembre 03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU / Linux

info d'erreur:

Référentiel Git vide initialisé dans /home/techops/pyenv/.git/ Mot de passe: erreur: lors de l'accès à https: //waterdrops@github.com/pyenv/pyenv.git/info/refs

fatal: échec de la requête HTTP

Informations sur la version de git & curl

git info: git version 1.7.1

curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl / 7.19.7 NSS / 3.14.0.0 zlib / 1.2.3 libidn / 1.18 libssh2 / 1.4.2 Protocoles: tftp ftp telnet dict ldap ldaps fichier http https ftps scp sftp Caractéristiques: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

débogage

$ curl --verbose https://github.com

  • À propos de la connexion () au port 443 de github.com (# 0)
  • Essayer 13.229.188.59 ... connecté
  • Connecté au port 443 (# 0) de github.com (13.229.188.59)
  • Initialisation de NSS avec certpath: sql: / etc / pki / nssdb
  • CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: aucun
  • Erreur NSS -12190
  • Erreur lors de la négociation TLS, en essayant SSLv3 ... GET / HTTP / 1.1 User-Agent: curl / 7.19.7 (x86_64-redhat-linux-gnu) libcurl / 7.19.7 NSS / 3.14.0.0 zlib / 1.2.3 libidn / 1.18 libssh2 / 1.4.2 Hôte: github.com Accepter: /

  • Connexion interrompue, nouvelle tentative de connexion

  • Fermeture de la connexion n ° 0
  • Envoyez une autre demande à cette URL: " https://github.com "
  • À propos de la connexion () au port 443 de github.com (# 0)
  • Essayer 13.229.188.59 ... connecté
  • Connecté au port 443 (# 0) de github.com (13.229.188.59)
  • TLS désactivé en raison d'un échec de la négociation précédente
  • CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: aucun
  • Erreur NSS -12286
  • Fermeture de la connexion n ° 0
  • Erreur de connexion SSL curl: (35) Erreur de connexion SSL

après la mise à jour de curl, libcurl et nss, git clone fonctionne à nouveau correctement, alors le voici. la commande de mise à jour est la suivante

sudo yum update -y nss curl libcurl


Merci - cela a fonctionné mieux pour moi avec bitbucket sur un repo sur l'ancien serveur CentOS 6.6 d'un client exécutant git 1.7.1
Eric Kigathi

J'ai ce problème avec gitlab-ci runner. Le travail va bien après la mise à niveau.
isca

6

Comme l'a dit JERC, assurez-vous d'avoir une version mise à jour de git. Si vous n'utilisez que les paramètres par défaut, lorsque vous essayez d'installer git, vous obtiendrez la version 1.7.1. Outre le téléchargement et l'installation manuels de la dernière version de get, vous pouvez également y parvenir en ajoutant un nouveau référentiel à yum.

Depuis tecadmin.net :

Téléchargez et installez le référentiel rpmforge:

# use this for 64-bit
rpm -i 'http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el6.rf.x86_64.rpm'
# use this for 32-bit
rpm -i 'http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el6.rf.i686.rpm'

# then run this in either case
rpm --import http://apt.sw.be/RPM-GPG-KEY.dag.txt

Ensuite, vous devez activer les rpmforge-extras. Modifiez /etc/yum.repos.d/rpmforge.repoet changez enabled = 0en enabled = 1sous [rpmforge-extras]. Le fichier ressemble à ceci:

### Name: RPMforge RPM Repository for RHEL 6 - dag
### URL: http://rpmforge.net/
[rpmforge]
name = RHEL $releasever - RPMforge.net - dag
baseurl = http://apt.sw.be/redhat/el6/en/$basearch/rpmforge
mirrorlist = http://mirrorlist.repoforge.org/el6/mirrors-rpmforge
#mirrorlist = file:///etc/yum.repos.d/mirrors-rpmforge
enabled = 1
protect = 0
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmforge-dag
gpgcheck = 1

[rpmforge-extras]
name = RHEL $releasever - RPMforge.net - extras
baseurl = http://apt.sw.be/redhat/el6/en/$basearch/extras
mirrorlist = http://mirrorlist.repoforge.org/el6/mirrors-rpmforge-extras
#mirrorlist = file:///etc/yum.repos.d/mirrors-rpmforge-extras
enabled = 0 ####### CHANGE THIS LINE TO "enabled = 1" #############
protect = 0
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmforge-dag
gpgcheck = 1

[rpmforge-testing]
name = RHEL $releasever - RPMforge.net - testing
baseurl = http://apt.sw.be/redhat/el6/en/$basearch/testing
mirrorlist = http://mirrorlist.repoforge.org/el6/mirrors-rpmforge-testing
#mirrorlist = file:///etc/yum.repos.d/mirrors-rpmforge-testing
enabled = 0
protect = 0
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmforge-dag
gpgcheck = 1

Une fois que vous avez fait cela, vous pouvez mettre à jour git avec

yum update git

Je ne sais pas pourquoi, mais ils suggèrent ensuite de désactiver rpmforge-extras (revenir à enabled = 0), puis de l'exécuter yum clean all.

Vous devrez probablement utiliser sudopour ces commandes.


Vraiment super réponse! Résolu mes problèmes sur Redhat (RHEL) 6.3.
Max

Au lieu d'éditer manuellement le fichier repo deux fois (activez d'abord les extras, puis désactivez-le à nouveau), je viens de courir yum install --enablerepo=rpmforge-extras gitet c'est tout!
alleen1

6

J'ai pu faire fonctionner un git 1.7.1 après un certain temps.

Tout d'abord, je devais désactiver SSL pour pouvoir extraire:

git config --global http.sslverify false

Alors je pourrais cloner

git clone https://github.com/USERNAME/PROJECTNAME.git

Ensuite, après avoir ajouté et engagé, j'étais incapable de repousser. Alors j'ai fait

git remote -v

origin  https://github.com/USERNAME/PROJECTNAME.git (fetch)
origin  https://github.com/USERNAME/PROJECTNAME.git (push)

pour voir les adresses pull et push:

Ceux-ci doivent être modifiés avec USERNAME @

git remote set-url origin https://USERNAME@github.com/USERNAME/PROJECTNAME.git

Il vous demandera toujours un mot de passe, que vous pouvez ajouter avec

USERNAME:PASSWORD@github.....

Mais ne faites pas cela, car vous enregistrez votre mot de passe en texte clair pour un vol facile.

J'ai dû faire cette combinaison car je ne pouvais pas faire fonctionner SSH en raison des limitations du pare-feu.


4

C'est la réponse la plus stupide à cette question, mais vérifiez l'état de GitHub . Celui-ci m'a eu :)


Message d'aujourd'hui: "Nous travaillons toujours pour atténuer une attaque DDoS très importante. Le site est désormais disponible pour certains utilisateurs, mais nous resterons dans l'état rouge jusqu'à ce que nous soyons certains que le site reste actif." Qui pirate GitHub? Vraiment?
BenDundee

évidemment pas homakov, il s'engage à maîtriser au lieu de DDoS
nurettin

3

J'ai eu le même problème et la même erreur. Dans mon cas, c'était le https_proxy non défini. La définition de la variable d'environnement https_proxy a résolu le problème.

$ export https_proxy=https://<porxy_addres>:<proxy_port>

Exemple:

$ export https_proxy=https://my.proxy.company.com:8000

J'espère que cela aidera quelqu'un.

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.