Não é possível clonar um repositório github no Linux via HTTPS

87

Estou tentando fazer um simples git clone https://github.com/org/project.gitem uma caixa CentOS, mas consigo:

erro: O URL solicitado retornou o erro: 401 ao acessar https://github.com/org/project.git/info/refs

fatal: falha na solicitação HTTP

Ele nunca me pede meu nome de usuário / senha, apenas falha.

Posso fazer exatamente a mesma chamada no meu Mac sem problemas - o que estou perdendo?

linux  git  github 
— Yarin
fonte
É uma caixa CentOS 6.3 totalmente aberta na nuvem - acesso à Internet não é um problema
— Yarin
@Yarin: Espero que você já tenha lido isso: help.github.com/articles/https-cloning-errors O último recurso seria usar ssh, eu acho. Além disso, você pode querer verificar o e-mail com o qual seu git está configurado ... não tenho certeza se ajuda, mas certifique-se de que corresponde ao que você usa com sua conta github.
— greg0ire
sim- nenhum desses check-out- literalmente copiando um comando funcional do meu terminal mac para o terminal Linux- nenhum prompt de senha, apenas craps out
— Yarin

Respostas:

210

A resposta era simples, mas não óbvia:

Ao invés de:

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

Faz:

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

ou (inseguro)

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

(Observe que, no último caso, sua senha pode ser visível por outros usuários em sua máquina executando ps u -u $youe aparecerá em texto não criptografado no histórico de seu shell por padrão)

Todas as 3 maneiras funcionam no meu Mac, mas apenas as 2 últimas funcionaram na caixa Linux remota. (Pensando nisso, provavelmente é porque eu tinha um nome de usuário git global configurado no meu Mac, enquanto na caixa remota eu não tinha? Esse pode ter sido o caso, mas a falta de solicitação de um nome de usuário me enganou. .)

Não vi isso documentado em nenhum lugar, então aqui está.

— Yarin
fonte
3
Obrigado por citar o git config --global user.namedetalhe, foi isso para mim!
— AlemãoK
Observe que a partir do git 1.7.10 , será solicitado um nome de usuário, de acordo com @JERC , então isso não deve ser mais um problema.
— Yarin
Tive o mesmo problema (com GIT 1.7.1, CentOS5), mas não consegui adicionar o nome de usuário / pwd no URL-s porque tive que instalar pacotes de repositórios Bitbucket privados (e, obviamente, não vou adicionar o nome de usuário e pw info em um composer.json / composer.lock). Porque o GIT não me permitiu digitá-los manualmente, tive que ir da maneira mais difícil e atualizei o GIT com a ajuda do RPM Forge Repository ( guru4hp.blogspot.hu/2012/08/… ). Eu segui o guia @muness encontrado aqui: serverfault.com/questions/448814/…
— hattila
2
Esta é a resposta se você estiver usando o git 1.7.1 no linux
— Louie Miranda
1
aplicável se usar qualquer coisa antes de 1.7.10
— Amit G
32

Você pode desabilitar manualmente a verificação SSL e tentar novamente. :)

git config --global http.sslverify false
— Chu-Siang Lai
fonte
3
Para o BeagleBone Black com Angstrom, opkg não fornece a versão necessária para fazer a verificação SSL, então esta é a única opção que descobri que funciona.
— Josiah
1
A instrução @flickerfly é válida ... nenhuma outra maneira de clonar usando https, exceto usando este método ao usar beaglebone black com Angstrom OS.
— Funky81
1
Funciona em Centos. Obrigado.
— 030 de
Desativar a verificação SSL é um pouco perigoso. Um man-in-the-middle malicioso poderia teoricamente enviar a você um repositório git modificado.
— Mark Doliner
Também tive que fazer isso ao usar GitLab
— Gerard
12

Certifique-se de ter git 1.7.10 ou posterior, agora ele solicita o usuário / senha corretamente. (Você pode baixar a versão mais recente aqui )

— JERC
fonte
4
Eu tive o mesmo problema, minha versão git era 1.7.1 quando eu atualizo para 1.7.10 agora ele solicita usuário / senha corretamente !!, (a versão 1.7.1 NÃO É O MESMO PARA 1.7.10) Por favor, verifique as versões antes para devotado.
— JERC
10

Tive que especificar o nome de usuário para trabalhar na versão 1.7.1 git:

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

Eu encontrei o mesmo problema, a mensagem de erro e as informações do sistema operacional são as seguintes

Informação do sistema operacional:

Versão 6.5 do CentOS (final)

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

informação do erro:

Repositório Git vazio inicializado em /home/techops/pyenv/.git/ Senha: erro: ao acessar https: //waterdrops@github.com/pyenv/pyenv.git/info/refs

fatal: falha na solicitação HTTP

informações da versão git e curl

informações do git: git versão 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 arquivo http https ftps scp sftp Recursos: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

depuração

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

  • Prestes a conectar () à porta 443 de github.com (# 0)
  • Tentando 13.229.188.59 ... conectado
  • Conectado a github.com (13.229.188.59), porta 443 (# 0)
  • Inicializando NSS com certpath: sql: / etc / pki / nssdb
  • CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: nenhum
  • Erro NSS -12190

  • Erro no handshake TLS, tentando 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 Aceitar: /

  • A conexão morreu, tentando uma nova conexão

  • Fechando conexão # 0
  • Emita outra solicitação para este URL: ' https://github.com '
  • Prestes a conectar () à porta 443 de github.com (# 0)
  • Tentando 13.229.188.59 ... conectado
  • Conectado a github.com (13.229.188.59), porta 443 (# 0)
  • TLS desativado devido a falha de handshake anterior
  • CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: nenhum
  • Erro NSS -12286
  • Fechando conexão # 0
  • Curl de erro de conexão SSL: (35) Erro de conexão SSL

depois de atualizar curl, libcurl e nss, o clone git funciona bem novamente, então aqui está. o comando de atualização é o seguinte

sudo yum update -y nss curl libcurl

— Warrren Liu
fonte
Obrigado - funcionou melhor para mim com bitbucket em um repo em um antigo servidor CentOS 6.6 do cliente executando git 1.7.1
— Eric Kigathi
Estou tendo esse problema com o gitlab-ci runner. O trabalho está bem após a atualização.
— isca
6

Como JERC disse, certifique-se de ter uma versão atualizada do git. Se você estiver usando apenas as configurações padrão, ao tentar instalar o git, você obterá a versão 1.7.1. Além de baixar e instalar manualmente a versão mais recente do get, você também pode fazer isso adicionando um novo repositório ao yum.

De tecadmin.net :

Baixe e instale o repositório 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

Então você precisa habilitar o rpmforge-extras. Edite /etc/yum.repos.d/rpmforge.repoe mude enabled = 0para enabled = 1abaixo [rpmforge-extras]. O arquivo tem a seguinte aparência:

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

Depois de fazer isso, você pode atualizar o git com

yum update git

Não tenho certeza do porquê, mas eles sugerem desabilitar rpmforge-extras (voltar para enabled = 0) e rodar yum clean all.

Provavelmente você precisará usar sudopara esses comandos.

— Rob Watts
fonte
Resposta realmente ótima! Resolvi meus problemas no Redhat (RHEL) 6.3.
— Máx.
Em vez de editar manualmente o arquivo repo duas vezes (primeiro habilitar extras e depois desabilitá-lo novamente), apenas executei yum install --enablerepo=rpmforge-extras gite pronto!
— alleen1
6

Consegui fazer o git 1.7.1 funcionar depois de algum tempo.

Primeiro, eu tive que desabilitar o SSL apenas para poder puxar:

git config --global http.sslverify false

Então eu poderia clonar

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

Então, depois de adicionar e confirmar, não fui capaz de retroceder. Então eu fiz

git remote -v

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

para ver os endereços de puxar e empurrar:

Estes devem ser modificados com USERNAME @

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

Ele ainda solicitará uma senha, que você pode adicionar com 

USERNAME:PASSWORD@github.....

Mas não faça isso, pois você salva sua senha em texto simples para fácil roubo.

Tive que fazer essa combinação, pois não consegui fazer o SSH funcionar devido às limitações do firewall.

— Heine Nørby
fonte
4

Esta é a resposta mais idiota para essa pergunta, mas verifique o status do GitHub . Este me pegou :)

— BenDundee
fonte
Mensagem de hoje: "Ainda estamos trabalhando para mitigar um grande ataque DDoS. O site agora está disponível para alguns usuários, mas permaneceremos com o status vermelho até termos certeza de que o site continuará ativo." Quem hackeia o GitHub? Realmente?
— BenDundee de
obviamente não é Homakov, ele se compromete a dominar em vez de DDoS
— nurettin
3

Eu tive o mesmo problema e erro. No meu caso foi o https_proxy não configurado. Definir a variável de ambiente https_proxy corrigiu o problema.

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

Exemplo:

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

Espero que isso ajude alguém.

— Senthil Kumar Sekar
fonte
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.