Не вдається клонувати репозиторій github у Linux через HTTPS


87

Я намагаюся зробити просте git clone https://github.com/org/project.git на вікні CentOS, але отримую:

помилка: Запитувана URL-адреса повернула помилку: 401 під час доступу до https://github.com/org/project.git/info/refs

фатально: помилка запиту HTTP

Це ніколи не запитує мені моє ім’я користувача / пароль, просто не вдається.

Я можу зробити точно такий же дзвінок на своєму Mac без проблем - чого мені не вистачає?


Його свіжо відкритий вікно CentOS 6.3 на хмарі - доступ до Інтернету не проблема
Ярін

@Yarin: Я вірю, ви вже це прочитали: help.github.com/articles/https-cloning-errors Останнім засобом було б використовувати ssh, я думаю. Крім того, ви можете перевірити електронну пошту, на яку налаштовано ваш git ... не впевнений, чи допомагає він, але переконайтесь, що він відповідає тій, яку ви використовуєте у своєму обліковому записі github.
greg0ire

так - ніхто з них не перевіряє - буквально копіює робочу команду з мого терміналу mac в термінал linux - немає запиту на введення пароля, просто виривається
Ярін

Відповіді:


210

Відповідь була проста, але не очевидна:

Замість:

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

робити:

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

або (невпевнено)

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

(Зверніть увагу, що в подальшому випадку ваш пароль можуть побачити інші користувачі на вашому комп'ютері при запуску ps u -u $youта за замовчуванням відображатиметься в чистому тексті в історії вашої оболонки)

Усі три способи працюють на моєму Mac, але лише два останні працювали на віддаленому Linux-боксі. (Подумавши про це, можливо, тому, що на моєму Mac було налаштовано глобальне ім’я користувача git , тоді як на віддаленому ящику я цього не зробив? Це могло бути так, але відсутність запиту на ім’я користувача спонукала мене .. .)

Ніде цього не бачив цього задокументованого, тому ось воно.


3
Дякую, що згадали git config --global user.nameдеталь, це було для мене!
GermanK

Зверніть увагу, що починаючи з git 1.7.10, вам буде запропоновано ввести ім’я користувача, відповідно до @JERC , тому це більше не повинно бути проблемою.
Ярін,

У мене була та ж проблема (з GIT 1.7.1, CentOS5), але я не зміг додати ім'я користувача / pwd до URL-адрес, оскільки мені довелося встановлювати пакети з приватних репозиторіїв Bitbucket (і, очевидно, я не буду додавати ім'я користувача та pw інформацію в composer.json / composer.lock). Becouse GIT не дозволив мені вводити їх вручну, мені довелося піти важким шляхом і оновив GIT за допомогою сховища RPM Forge ( guru4hp.blogspot.hu/2012/08/… ). Я дотримувався керівництва @muness ', яке знайдено тут: serverfault.com/questions/448814/…
hattila

2
Це відповідь, якщо ви використовуєте git 1.7.1 на linux
Louie Miranda

1
застосовано, якщо що-небудь використовували до 1.7.10
Amit G

32

Ви можете вручну вимкнути ssl verfiy і повторити спробу. :)

git config --global http.sslverify false

3
Для BeagleBone Black з Angstrom opkg не надає потрібної версії для перевірки ssl, тому це єдиний вибір, який, на мою думку, працює.
Джосія

1
Оператор @flickerfly є дійсним .. немає іншого способу клонування за допомогою https, крім використання цього методу при використанні бігбоуна чорного кольору з ОС Angstrom.
Funky81

1
Працює над Centos. Дякую.
030

Вимкнути перевірку ssl трохи небезпечно. Шкідливий посередник теоретично може надіслати вам модифікований репозиторій git.
Mark Doliner

Також це потрібно було робити при використанні GitLab
Gerard

12

Переконайтеся, що у вас є git 1.7.10 або пізнішої версії, тепер він правильно запитує користувача / пароль. (Ви можете завантажити останню версію тут )


4
У мене була та ж проблема. Моя версія git була 1.7.1, коли я переходжу до версії 1.7.10. Зараз він підказує Користувач / Пароль правильно !!, (версія 1.7.1 НЕ ТАКА ж, до 1.7.10) до відданих.
JERC

10

Мені довелося вказати ім'я користувача для роботи з версією 1.7.1 git:

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

10

Я зіткнувся з тією ж проблемою, повідомлення про помилку та інформація про ОС такі

Інформація про ОС:

Випуск CentOS 6.5 (остаточний)

Linux 192-168-30-213 2.6.32-431.el6.x86_64 # 1 SMP пт 22 листопада 03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU / Linux

інформація про помилку:

Ініціалізоване порожнє сховище Git у /home/techops/pyenv/.git/ Пароль: помилка: при доступі до https: //waterdrops@github.com/pyenv/pyenv.git/info/refs

фатально: помилка запиту HTTP

інформація про версію git & curl

інформація про git: версія git 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 Протоколи: tftp ftp telnet dict ldap ldaps http файл https ftps scp sftp Особливості: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

налагодження

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

  • Про підключення () до порту 443 github.com (# 0)
  • Спроба 13.229.188.59 ... підключена
  • Підключений до порту 443 github.com (13.229.188.59) (# 0)
  • Ініціалізація NSS за допомогою certpath: sql: / etc / pki / nssdb
  • CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none
  • Помилка NSS -12190
  • Помилка в рукостисканні TLS, спроба 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 Хост: github.com Прийняти: /

  • Зв'язок помер, повторна спроба встановити нове з'єднання

  • Закриття з'єднання №0
  • Надішліть ще один запит за цією URL-адресою: ' https://github.com '
  • Про підключення () до порту 443 github.com (# 0)
  • Спроба 13.229.188.59 ... підключена
  • Підключений до порту 443 github.com (13.229.188.59) (# 0)
  • TLS вимкнено через попередню помилку рукостискання
  • CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none
  • Помилка NSS -12286
  • Закриття з'єднання №0
  • Завитка помилки з'єднання SSL: (35) Помилка з'єднання SSL

після оновлення curl, libcurl і nss, git clone знову працює нормально, от і ось. команда оновлення така

sudo yum update -y nss curl libcurl


Дякую - це найкраще для мене працювало з bitbucket на репо на старому клієнтському сервері CentOS 6.6 під управлінням git 1.7.1
Eric Kigathi

У мене проблема з бігуном gitlab-ci. Після оновлення робота працює нормально.
isca,

6

Як сказав JERC, переконайтесь, що у вас є оновлена ​​версія git. Якщо ви використовуєте лише налаштування за замовчуванням, при спробі встановити git ви отримаєте версію 1.7.1. Окрім ручного завантаження та встановлення останньої версії get, ви також можете досягти цього, додавши нове сховище до yum.

Від tecadmin.net :

Завантажте та встановіть сховище 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

Потім потрібно ввімкнути rpmforge-extras. Відредагуйте /etc/yum.repos.d/rpmforge.repoта змініть enabled = 0на enabled = 1під [rpmforge-extras]. Файл виглядає так:

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

Після цього ви можете оновити git за допомогою

yum update git

Я не впевнений, чому, але тоді вони пропонують відключити rpmforge-extras (змінити на enabled = 0), а потім запустити yum clean all.

Швидше за все вам доведеться використовувати sudoдля цих команд.


Дійсно чудова відповідь! Вирішив мої проблеми на Redhat (RHEL) 6.3.
Макс.

Замість того, щоб вручну редагувати файл репо двічі (спочатку увімкніть додаткові функції, а потім знову вимкніть), я просто побіг, yum install --enablerepo=rpmforge-extras gitі це кинуло!
alleen1

6

Я зміг змусити git 1.7.1 запрацювати через деякий час.

По-перше, мені довелося відключити SSL, щоб я міг витягнути:

git config --global http.sslverify false

Тоді я міг клонувати

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

Тоді після додавання та фіксації я був НЕ МОЖНИМ відштовхуватися. Так я і зробив

git remote -v

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

щоб побачити адреси натягування та натискання:

Вони повинні бути змінені за допомогою USERNAME @

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

Він все одно запропонує вам ввести пароль, який ви можете додати

USERNAME:PASSWORD@github.....

Але не робіть цього, оскільки ви зберігаєте свій пароль у чистому тексті для легкої крадіжки.

Мені довелося зробити цю комбінацію, оскільки я не міг змусити SSH працювати через обмеження брандмауера.


4

Це найдурніша відповідь на це питання, але перевірте статус GitHub . Цей мене зрозумів :)


Повідомлення від сьогодні: "Ми все ще працюємо над пом'якшенням дуже великої DDoS-атаки. Сайт тепер доступний для деяких користувачів, але ми залишатимемося в червоному статусі, поки не будемо впевнені, що сайт продовжує працювати". Хто зламає GitHub? Справді?
BenDundee

очевидно, не хомаков, він зобов'язується опанувати замість DDoS
нуреттин

3

У мене були однакові проблеми та помилки. У моєму випадку це був не встановлений https_proxy. Налаштування змінної середовища https_proxy вирішило проблему.

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

Приклад:

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

Сподіваюся, це комусь допоможе.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.