Nie można sklonować repozytorium Github w systemie Linux za pośrednictwem protokołu HTTPS

87

Próbuję zrobić proste git clone https://github.com/org/project.gitna pudełku CentOS, ale otrzymuję:

błąd: żądany adres URL zwrócił błąd: 401 podczas uzyskiwania dostępu do https://github.com/org/project.git/info/refs

krytyczny: żądanie HTTP nie powiodło się

Nigdy nie pyta mnie o moją nazwę użytkownika / hasło, po prostu kończy się niepowodzeniem.

Mogę wykonać dokładnie to samo połączenie na moim Macu, bez problemu - czego mi brakuje?

linux  git  github 
— Yarin
źródło
To świeże, szeroko otwarte pudełko CentOS 6.3 w chmurze - dostęp do Internetu nie stanowi problemu
— Yarin
@Yarin: Ufam, że już to przeczytałeś: help.github.com/articles/https-cloning-errors Ostatnią deską ratunku byłoby użycie ssh. Możesz również sprawdzić adres e-mail, z którym jest skonfigurowany Twój git ... nie jestem pewien, czy to pomaga, ale upewnij się, że odpowiada temu, którego używasz z kontem github.
— greg0ire
tak - żadna z tych osób nie sprawdza - dosłownie kopiuje działające polecenie z mojego terminala Mac do terminala linux - bez pytania o hasło, po prostu wypadają
— Yarin

Odpowiedzi:

210

Odpowiedź była prosta, ale nieoczywista:

Zamiast:

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

zrobić:

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

lub (niepewne)

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

(Zauważ, że w późniejszym przypadku twoje hasło może być widoczne dla innych użytkowników twojego komputera po uruchomieniu ps u -u $youi domyślnie pojawi się w historii twojej powłoki jako zwykły tekst)

Wszystkie 3 sposoby działają na moim Macu, ale tylko ostatnie 2 działały na zdalnym Linuksie. (Myśląc o tym, prawdopodobnie dlatego, że miałem skonfigurowaną globalną nazwę użytkownika git na moim Macu, podczas gdy na zdalnym skrzynce nie zrobiłem tego? Mogło tak być, ale brak monitu o podanie nazwy użytkownika zaskoczył mnie ... .)

Nigdzie nie widziałem tego udokumentowanego, więc oto jest.

— Yarin
źródło
3
Dziękuję za wspomnienie o git config --global user.nameszczegółach, to było to dla mnie!
— GermanK
Zauważ, że od wersji git 1.7.10 zostaniesz poproszony o podanie nazwy użytkownika, zgodnie z @JERC , więc nie powinno to już stanowić problemu ...
— Yarin
Miałem ten sam problem (z GIT 1.7.1, CentOS5), ale nie mogłem dodać nazwy użytkownika / pwd do adresów URL, ponieważ musiałem instalować pakiety z prywatnych repozytoriów Bitbucket (i oczywiście nie dodam nazwy użytkownika i pw do pliku composer.json / composer.lock). Ponieważ GIT nie pozwalał mi wpisywać ich ręcznie, musiałem przejść całą ciężką drogę i zaktualizować GIT przy pomocy repozytorium RPM Forge ( guru4hp.blogspot.hu/2012/08/… ). Postępowałem zgodnie z przewodnikiem @muness, który można znaleźć tutaj: serverfault.com/questions/448814/…
— hattila
2
To jest odpowiedź, jeśli używasz git 1.7.1 w systemie Linux
— Louie Miranda
1
ma zastosowanie, jeśli używasz czegokolwiek sprzed 1.7.10
— Amit G
32

Możesz ręcznie wyłączyć weryfikację SSL i spróbować ponownie. :)

git config --global http.sslverify false
— Chu-Siang Lai
źródło
3
W przypadku BeagleBone Black z Angstromem, opkg nie dostarcza wymaganej wersji do weryfikacji SSL, więc jest to jedyny wybór, który sprawdziłam.
— Josiah,
1
Oświadczenie @flickerfly jest poprawne… nie ma innego sposobu na klonowanie przy użyciu protokołu https, z wyjątkiem użycia tej metody w przypadku używania beaglebone black z systemem Angstrom OS.
— Funky81
1
Działa na Centos. Dziękuję Ci.
— 030
Wyłączenie weryfikacji SSL jest nieco niebezpieczne. Złośliwy man-in-the-middle mógłby teoretycznie wysłać zmodyfikowane repozytorium git.
— Mark Doliner
Musiałem to również zrobić podczas korzystania z GitLab
— Gerard
12

Upewnij się, że masz git w wersji 1.7.10 lub nowszej, teraz wyświetla poprawnie użytkownika / hasło. (Możesz pobrać najnowszą wersję tutaj )

— JERC
źródło
4
Miałem ten sam problem, moja wersja git to 1.7.1, kiedy aktualizuję do 1.7.10, teraz wyświetla monit o użytkownika / hasło!, (Wersja 1.7.1 NIE JEST TAKI SAMA, CO 1.7.10) Proszę sprawdzić wersje wcześniej oddany.
— JERC
10

Musiałem podać nazwę użytkownika, aby pracować na wersji 1.7.1 git:

git remote set-url origin https://username@github.com/org/project.git
— Andrius
źródło
10

Spotkałem ten sam problem, komunikat o błędzie i informacje o systemie są następujące

Informacje o systemie operacyjnym:

Wersja CentOS 6.5 (wersja ostateczna)

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

informacje o błędzie:

Zainicjowano puste repozytorium Git w /home/techops/pyenv/.git/ Hasło: błąd: podczas uzyskiwania dostępu do https: //waterdrops@github.com/pyenv/pyenv.git/info/refs

krytyczny: żądanie HTTP nie powiodło się

Informacje o wersji git i curl

Informacje o git: git w wersji 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 Protokoły: tftp ftp telnet dict ldap ldaps plik http https ftps scp sftp Cechy: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

debugowanie

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

  • Zamierzam połączyć () z portem 443 na github.com (# 0)
  • Próbuję 13.229.188.59 ... połączono
  • Połączono z github.com (13.229.188.59), port 443 (# 0)
  • Inicjowanie NSS za pomocą certpath: sql: / etc / pki / nssdb
  • CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: brak
  • Błąd NSS -12190

  • Błąd podczas uzgadniania TLS, próba 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 Host: github.com Akceptuj: /

  • Połączenie zostało przerwane, ponawiając próbę nowego połączenia

  • Zamykanie połączenia # 0
  • Wyślij kolejne żądanie na ten adres URL: „ https://github.com ”
  • Zamierzam połączyć () z portem 443 na github.com (# 0)
  • Próbuję 13.229.188.59 ... połączono
  • Połączono z github.com (13.229.188.59), port 443 (# 0)
  • Protokół TLS wyłączony z powodu poprzedniego niepowodzenia uzgadniania
  • CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: brak
  • Błąd NSS -12286
  • Zamykanie połączenia # 0
  • Błąd połączenia SSL curl: (35) Błąd połączenia SSL

po aktualizacji curl, libcurl i nss, git clone znów działa dobrze, więc oto jest. polecenie aktualizacji jest następujące

sudo yum update -y nss curl libcurl

— Warrren Liu
źródło
Dzięki - to działało najlepiej dla mnie z bitbucket w repozytorium na starym serwerze klienta CentOS 6.6 z systemem git 1.7.1
— Eric Kigathi
Mam ten problem z gitlab-ci runner. Po uaktualnieniu praca jest w porządku.
— isca
6

Jak powiedział JERC, upewnij się, że masz zaktualizowaną wersję git. Jeśli używasz tylko ustawień domyślnych, podczas próby zainstalowania gita otrzymasz wersję 1.7.1. Oprócz ręcznego pobierania i instalowania najnowszej wersji get, możesz to również osiągnąć, dodając nowe repozytorium do yum.

Z tecadmin.net :

Pobierz i zainstaluj repozytorium 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

Następnie musisz włączyć dodatki rpmforge. Edytuj /etc/yum.repos.d/rpmforge.repoi zmień enabled = 0na enabled = 1poniżej [rpmforge-extras]. Plik wygląda następująco:

### 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

Gdy to zrobisz, możesz zaktualizować git za pomocą

yum update git

Nie jestem pewien dlaczego, ale następnie sugerują wyłączenie rpmforge-extras (zmiana z powrotem na enabled = 0), a następnie uruchomienie yum clean all.

Najprawdopodobniej będziesz musiał użyć sudotych poleceń.

— Rob Watts
źródło
Naprawdę świetna odpowiedź! Rozwiązałem moje problemy na Redhat (RHEL) 6.3.
— Maksymalnie
Zamiast ręcznie edytować plik repozytorium dwukrotnie (najpierw włącz dodatki, a następnie wyłącz go ponownie), po prostu uruchomiłem yum install --enablerepo=rpmforge-extras giti to wszystko!
— alleen1
6

Po jakimś czasie udało mi się uruchomić git 1.7.1.

Najpierw musiałem wyłączyć SSL, aby móc wyciągnąć:

git config --global http.sslverify false

Wtedy mogłem klonować

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

Następnie po dodaniu i zatwierdzeniu nie mogłem odrzucić. Więc zrobiłem

git remote -v

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

aby zobaczyć adresy pull i push:

Te muszą zostać zmodyfikowane przez USERNAME @

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

Nadal poprosi o hasło, które możesz dodać 

USERNAME:PASSWORD@github.....

Ale nie rób tego, ponieważ zapisujesz hasło w postaci zwykłego tekstu, aby ułatwić kradzież.

Musiałem zrobić tę kombinację, ponieważ nie mogłem uruchomić SSH z powodu ograniczeń zapory.

— Heine Nørby
źródło
4

To najgłupsza odpowiedź na to pytanie, ale sprawdź stan GitHuba . Ten mnie dopadł :)

— BenDundee
źródło
Wiadomość z dnia dzisiejszego: „Nadal pracujemy nad złagodzeniem bardzo dużego ataku DDoS. Witryna jest teraz dostępna dla niektórych użytkowników, ale pozostaniemy na czerwono, dopóki nie upewnimy się, że witryna nadal działa”. Kto włamuje się do GitHuba? Naprawdę?
— BenDundee,
oczywiście nie homakow, zobowiązuje się do masteringu zamiast DDoS
— nurettin
3

Miałem ten sam problem i błąd. W moim przypadku nie ustawiono https_proxy. Ustawienie zmiennej środowiskowej https_proxy rozwiązało problem.

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

Przykład:

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

Mam nadzieję, że to komuś pomoże.

— Senthil Kumar Sekar
źródło
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.