No se puede clonar un repositorio de github en Linux a través de HTTPS

87

Estoy tratando de hacer algo simple git clone https://github.com/org/project.giten una caja CentOS pero obtengo:

error: la URL solicitada devolvió el error: 401 al acceder a https://github.com/org/project.git/info/refs

fatal: la solicitud HTTP falló

Nunca me pide mi nombre de usuario / contraseña, simplemente falla.

Puedo hacer exactamente la misma llamada en mi Mac sin problema, ¿qué me estoy perdiendo?

linux  git  github 
— Yarin
fuente
Es una caja CentOS 6.3 completamente abierta en la nube: el acceso a Internet no es un problema
— Yarin
@Yarin: Confío en que ya leyó esto: help.github.com/articles/https-cloning-errors El último recurso sería usar ssh, creo. Además, es posible que desee verificar el correo electrónico con el que está configurado su git ... no estoy seguro de si ayuda, pero asegúrese de que corresponda al que usa con su cuenta de github.
— greg0ire
sí, ninguno de esos verifica, literalmente copiando un comando de trabajo desde mi terminal mac a la terminal de linux, sin solicitud de contraseña, solo caga
— Yarin

Respuestas:

210

La respuesta fue simple pero no obvia:

En vez de:

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

hacer:

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

o (inseguro)

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

(Tenga en cuenta que en el último caso, su contraseña será visible para otros usuarios en su máquina al ejecutarla ps u -u $youy aparecerá como texto sin cifrar en el historial de su shell de forma predeterminada)

Las 3 formas funcionan en mi Mac, pero solo las 2 últimas funcionaron en la caja de Linux remota. (Pensando en esto, probablemente se deba a que tenía un nombre de usuario de git global configurado en mi Mac, mientras que en el cuadro remoto no lo tenía. Ese podría haber sido el caso, pero la falta de solicitud de un nombre de usuario me hizo tropezar ... .)

No he visto esto documentado en ninguna parte, así que aquí está.

— Yarin
fuente
3
Gracias por mencionar el git config --global user.namedetalle, ¡eso fue todo para mí!
— GermanK
Tenga en cuenta que a partir de git 1.7.10 se le pedirá un nombre de usuario, según @JERC , por lo que esto ya no debería ser un problema ..
— Yarin
Tuve el mismo problema (con GIT 1.7.1, CentOS5), pero no pude agregar el nombre de usuario / pwd en las URL porque tuve que instalar paquetes desde repositorios privados de Bitbucket (y obviamente no agregaré nombre de usuario y pw info en un composer.json / composer.lock). Debido a que GIT no me permitió escribirlos manualmente, tuve que ir por el camino difícil y actualicé GIT con la ayuda del Repositorio de RPM Forge ( guru4hp.blogspot.hu/2012/08/… ). Seguí la guía de @muness que se encuentra aquí: serverfault.com/questions/448814/…
— hattila
2
Esta es la respuesta si está usando git 1.7.1 en linux
— Louie Miranda
1
aplicable si se usa algo antes de 1.7.10
— Amit G
32

Puede desactivar manualmente la verificación de SSL y volver a intentarlo. :)

git config --global http.sslverify false
— Chu-Siang Lai
fuente
3
Para el BeagleBone Black con Angstrom, opkg no proporciona la versión requerida para realizar la verificación SSL, por lo que esta es la única opción que he encontrado que funciona.
— Josiah
1
La declaración @flickerfly es válida ... no hay otra forma de clonar usando https excepto usando este método cuando se usa beaglebone black con Angstrom OS.
— Funky81
1
Funciona en Centos. Gracias.
— 030
Deshabilitar la verificación SSL es un poco peligroso. En teoría, un intermediario malicioso podría enviarle un repositorio de git modificado.
— Mark Doliner
También tuve que hacer esto al usar GitLab
— Gerard
12

Asegúrate de tener git 1.7.10 o posterior, ahora solicita el usuario / contraseña correctamente. (Puede descargar la última versión aquí )

— JERC
fuente
4
Tuve el mismo problema, mi versión de git era 1.7.1 cuando actualizo a 1.7.10 ahora ¡¡Muestra usuario / contraseña correctamente !!, (la versión 1.7.1 NO ES IGUAL A 1.7.10) Verifique las versiones antes a dedicado.
— JERC
10

Tuve que especificar el nombre de usuario para trabajar en la versión 1.7.1 de git:

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

Encontré el mismo problema, el mensaje de error y la información del sistema operativo son los siguientes

Información del sistema operativo:

Versión 6.5 de CentOS (final)

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

información de error:

Repositorio de Git vacío inicializado en /home/techops/pyenv/.git/ Contraseña: error: al acceder a https: //waterdrops@github.com/pyenv/pyenv.git/info/refs

fatal: la solicitud HTTP falló

información de la versión de git y curl

git info: git versión 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 Protocolos: tftp ftp telnet dict ldap ldaps archivo http https ftps scp sftp Características: GSS-Negociar IDN IPv6 Largefile NTLM SSL libz

depuración

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

  • A punto de conectarse () al puerto 443 de github.com (# 0)
  • Intentando 13.229.188.59 ... conectado
  • Conectado a github.com (13.229.188.59) puerto 443 (# 0)
  • Inicialización de NSS con certpath: sql: / etc / pki / nssdb
  • CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: ninguno
  • Error NSS -12190

  • Error en el protocolo de enlace TLS, probando 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 Aceptar: /

  • La conexión murió, volviendo a intentar una nueva conexión

  • Cerrando conexión # 0
  • Emita otra solicitud a esta URL: ' https://github.com '
  • A punto de conectarse () al puerto 443 de github.com (# 0)
  • Intentando 13.229.188.59 ... conectado
  • Conectado a github.com (13.229.188.59) puerto 443 (# 0)
  • TLS deshabilitado debido a una falla de protocolo de enlace anterior
  • CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: ninguno
  • Error NSS -12286
  • Cerrando conexión # 0
  • Curl de error de conexión SSL: (35) Error de conexión SSL

después de actualizar curl, libcurl y nss, git clone funciona bien nuevamente, así que aquí está. el comando de actualización es el siguiente

sudo yum update -y nss curl libcurl

— Warrren Liu
fuente
Gracias, esto funcionó mejor para mí con bitbucket en un repositorio en el antiguo servidor CentOS 6.6 de un cliente que ejecuta git 1.7.1
— Eric Kigathi
Tengo este problema con gitlab-ci runner. El trabajo está bien después de la actualización.
— isca
6

Como dijo JERC, asegúrese de tener una versión actualizada de git. Si solo está usando la configuración predeterminada, cuando intente instalar git obtendrá la versión 1.7.1. Además de descargar e instalar manualmente la última versión de get, también puede lograr esto agregando un nuevo repositorio a yum.

Desde tecadmin.net :

Descargue e instale el repositorio 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

Entonces necesitas habilitar rpmforge-extras. Edite /etc/yum.repos.d/rpmforge.repoy cambie enabled = 0a enabled = 1debajo [rpmforge-extras]. El archivo se ve así:

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

Una vez que hayas hecho esto, puedes actualizar git con

yum update git

No estoy seguro de por qué, pero luego sugieren deshabilitar rpmforge-extras (volver a cambiar a enabled = 0) y luego ejecutarlo yum clean all.

Lo más probable es que necesite utilizar sudoestos comandos.

— Rob Watts
fuente
¡Realmente una gran respuesta! Resolví mis problemas en Redhat (RHEL) 6.3.
— Max
En lugar de editar manualmente el archivo de repositorio dos veces (primero habilite los extras y luego deshabilítelo nuevamente), ¡simplemente ejecuté yum install --enablerepo=rpmforge-extras gity listo!
— alleen1
6

Pude hacer que un git 1.7.1 funcionara después de bastante tiempo.

Primero, tuve que deshabilitar SSL solo para poder tirar:

git config --global http.sslverify false

Entonces podría clonar

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

Luego, después de agregar y comprometer, no pude rechazar. Así que lo hice

git remote -v

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

para ver las direcciones pull y push:

Deben modificarse con USERNAME @

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

Todavía le pedirá una contraseña, que puede agregar con 

USERNAME:PASSWORD@github.....

Pero no hagas eso, ya que guardas tu contraseña en texto sin cifrar para facilitar el robo.

Tuve que hacer esta combinación ya que no pude hacer que SSH funcionara debido a las limitaciones del firewall.

— Heine Nørby
fuente
4

Esta es la respuesta más tonta a esta pregunta, pero verifique el estado de GitHub . Este me atrapó :)

— BenDundee
fuente
Mensaje de hoy: "Todavía estamos trabajando para mitigar un ataque DDoS muy grande. El sitio ahora está disponible para algunos usuarios, pero permaneceremos en estado rojo hasta que estemos seguros de que el sitio se mantendrá activo". ¿Quién hackea GitHub? De Verdad?
— BenDundee
obviamente no Homakov, se compromete a dominar en lugar de DDoS
— nurettin
3

Tuve el mismo problema y error. En mi caso, no se configuró https_proxy. La configuración de la variable de entorno https_proxy solucionó el problema.

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

Ejemplo:

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

Espero que esto ayude a alguien.

— Senthil Kumar Sekar
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.