GitLab - Não aceita pushes via SSH [pede senha SSH], funciona com HTTP?

Question

Eu olhei para várias soluções para esse problema, incluindo: link O Gitlab não funciona com chaves SSH link

Ok, então ... acabei de instalar o GitLab hoje. Eu segui este manual . Quando eu comecei a criar o usuário, "git" estava em uso, então decidi usar o "gitlab". Se esta foi uma má decisão, eu posso voltar e tentar ver o que está usando "git" e por que e se eu posso parar com isso e dar para o GitLab.

Basicamente, quando eu envio o GitLab, estou tentando usar o endereço SSH: [email protected]: user / repo. Quando eu uso "git push origin master" (com origem apontando para o endereço acima mencionado), me perguntam a senha do usuário "gitlab" para o servidor SSH. Se eu entrar, o GitLab me diz que "user / repo" não parece ser um repositório e então sai.

A saída de "ssh -vvvT" é:

C:\Users\Jake>ssh -vvvT [email protected]
OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007
debug2: ssh_connect: needpriv 0
debug1: Connecting to git.redacted.com [redacted] port 22.
debug1: Connection established.
debug1: identity file /c/Users/Jake/.ssh/identity type -1
debug3: Not a RSA1 key file /c/Users/Jake/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'Proc-Type:'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'DEK-Info:'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /c/Users/Jake/.ssh/id_rsa type 1
debug3: Not a RSA1 key file /c/Users/Jake/.ssh/id_dsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'Proc-Type:'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'DEK-Info:'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /c/Users/Jake/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubu
ntu-2ubuntu2
debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.6
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-g
roup-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1
28,arcfour256,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-c
tr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1
28,arcfour256,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-c
tr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open
ssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open
ssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: [email protected],ecdh-sha2-nistp256,ecdh-
sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hel
lman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour12
8,[email protected],[email protected],[email protected],ae
s128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndae
[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour12
8,[email protected],[email protected],[email protected],ae
s128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndae
[email protected]
debug2: kex_parse_kexinit: [email protected],[email protected],um
[email protected],[email protected],[email protected],hma
[email protected],[email protected],hmac-sha1-96-etm@opens
sh.com,[email protected],hmac-md5,hmac-sha1,[email protected],umac-1
[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh
.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: [email protected],[email protected],um
[email protected],[email protected],[email protected],hma
[email protected],[email protected],hmac-sha1-96-etm@opens
sh.com,[email protected],hmac-md5,hmac-sha1,[email protected],umac-1
[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh
.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 119/256
debug2: bits set: 524/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /c/Users/Jake/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug3: check_host_in_hostfile: filename /c/Users/Jake/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug1: Host 'git.majornoob.com' is known and matches the RSA host key.
debug1: Found key in /c/Users/Jake/.ssh/known_hosts:1
debug2: bits set: 515/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /c/Users/Jake/.ssh/identity (0x0)
debug2: key: /c/Users/Jake/.ssh/id_rsa (0xa01b360)
debug2: key: /c/Users/Jake/.ssh/id_dsa (0xa01b378)
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /c/Users/Jake/.ssh/identity
debug3: no such identity: /c/Users/Jake/.ssh/identity
debug1: Offering public key: /c/Users/Jake/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Offering public key: /c/Users/Jake/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
[email protected]'s password:

C:\Users\Jake>

Isso parece ter problemas para ler minhas chaves SSH? Não tenho certeza do que está acontecendo.

Eu tentei duas chaves SSH diferentes com dois tipos diferentes de criptografia usando os seguintes comandos:

ssh-keygen -t rsa -C "[email protected]"
ssh-keygen -t dsa -C "[email protected]"

Aqui está a saída se eu tentar enviar o protocolo SSH:

C:\Users\Jake\Documents\Development\test>git push origin master
[email protected]'s password:
fatal: 'jake/test.git' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

C:\Users\Jake\Documents\Development\test>

Por que isso é mesmo pedir a senha do SSH? Eu quero usar chaves.

As chaves estão na instalação do GitLab, aqui está uma prova disso:

Nãoseiaocertoparaondeirouquaisoutrasinformaçõespossofornecerparafacilitarodiagnósticodomeuproblema.Porfavor,meajude!Euvouobrigaraqualquerperguntaquevocêfizerquepossatornarissomaisfácilparavocê.

Obrigadoantecipadamente!

edit:Quandoeuuso"ssh -vvvT [email protected]" e na verdade insiro a senha para o usuário, ele mostra o Ubuntu MOTD. Tenho quase 200% de certeza de que isso não deveria acontecer.

    

Answer 1

Você está certo. o MOTD deve não ser exibido para qualquer usuário. O Gitlab tem seu próprio shell integrado que manipula os usuários, mas esse shell é executado apenas quando um usuário efetua login com sua chave privada, o que não funciona para você. Como o login como git com uma senha leva você a um prompt, você deve excluir a senha do git:

sudo passwd -d git

E, em seguida, desabilite o login com bash executando sudo vim /etc/passwd , encontre o usuário git e, no final, onde diz /bin/bash , substitua-o por /bin/nologin .

Quanto às chaves, verifique se o seu computador cliente pode usar chaves. Tente sshing para localhost. Deve pedir uma senha. Saia, adicione a chave ssh do cliente a si mesma com:

cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys #This should not require root

Em seguida, tente fazer login no host local novamente. Se não pedir uma senha, você sabe que seu cliente está configurado corretamente.

Se o seu cliente estiver bem, tente depurar o servidor. ANTES você faz isso, exclua suas chaves da captura de tela. Então, certifique-se de que o Gitlab tenha acesso total ao diretório /home/git/.ssh executando sudo chmod -R git /home/git/.ssh . Adicione novamente as chaves e, em seguida, execute sudo cat /home/git/.ssh/authorized_keys e veja se suas chaves estão lá.

Se isso não funcionar, confira os registros do gitlab executando tailf /home/git/gitlab/{LOG}.log e, em seguida, substitua {LOG} por unicorn , application , production ou githost e, depois, adicione suas chaves.

LEMBRE-SE de apagar suas chaves antes de fazer qualquer coisa. As chaves são armazenadas no banco de dados e devem ser armazenadas em /home/git/.ssh/authorized_keys. Se eles estiverem no banco de dados, mas não no arquivo, você poderá ter problemas.

    

Answer 2

Minha situação

Servidor: Ubuntu 14.04.1 Atualizando para as últimas versões do pacote (sudo apt-get update & sudo apt-get dist-upgrade). Gitlab: 6.9.0 (a versão gitlab não importa realmente).

Tudo funcionou perfeitamente antes de atualizar e reiniciar o servidor, com as chaves ssh corretas e todas as coisas relacionadas. Mas depois de atualizar os pacotes, todos os usuários foram impedidos para uma operação normal, mas solicitando a senha do usuário "git".

O que eu fiz?

Depois de várias horas, descobri o que realmente aconteceu: novas verificações de permissão no diretório /home/git ao executar comandos git.

Passos para verificar se isso serve para o seu caso:

1. tail -f /var/log/auth.log
2. Tente fazer uma operação do git (como git remote update ).
3. Verifique o arquivo de log. Uma linha como esta apareceu: Authentication refused: bad ownership or modes for directory /home/git .
4. Assegure-se de que o proprietário de /home/git : sudo chown git:git /home/git .
5. Garanta permissões de diretório: sudo chmod 755 /home/git .
6. Coloque no repositório git e faça git remote update sem nenhum problema.

Isso funcionou para mim !!!