Que “direitos de acesso” poderiam estar bloqueando o acesso a um repositório gitlab?

Question

Estou tentando configurar o gitlab (6.5.1) em um novo servidor limpo. Tudo parece funcionar, mas git é incapaz de empurrar para qualquer projeto. Seguindo os comandos da página do projeto recém-criada e empurrando para o controle remoto via ssh dá:

$ git push -u origin master
fatal: Could not read from remote repository.

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

Este parece ser um problema bastante comum. Infelizmente, parece ter várias causas potenciais e nenhuma delas parece combinar. A partir da edição 3424 em uma versão antiga e várias outras fontes on-line, vi e verifiquei as seguintes sugestões:

• Chaves ssh restantes

  Esta é uma configuração limpa sem sobras. Minha chave foi adicionada ao arquivo de chaves autorizadas corretamente e é a única listada.

• A execução do ssh com o log de depuração mostra erros relacionados ao ambiente do Ruby.

  A minha vem limpa. O SSH debug mostra uma conexão bem-sucedida. Tudo sobre o handshaking de autenticação é normal, então este é o fim da saída:

  debug1: Sending command: git-receive-pack 'username/reponame.git'
  debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
  debug1: client_input_channel_req: channel 0 rtype [email protected] reply 0
  debug1: channel 0: free: client-session, nchannels 1
  debug1: fd 0 clearing O_NONBLOCK
  debug1: fd 1 clearing O_NONBLOCK
  

• Problemas com o ambiente do gitlab-shell.

  Ao contrário de muitos outros com a mesma mensagem de erro acima, meu script de verificação do gitlab-shell retorna um atestado de integridade:

  % sudo -u gitlab -H ~gitlab/gitlab-shell/bin/check   
  Check GitLab API access: OK
  Check directories and files: 
          /var/lib/gitlab/repositories: OK
          /var/lib/gitlab/.ssh/authorized_keys: OK
  Test redis-cli executable: redis-cli 2.8.5
  Send ping to redis server: PONG
  

• Reinicie {unicorn, sidekiq, redis}

  Os relatórios que reiniciaram um ou mais serviços eliminam isso não parecem se aplicar aqui. Este não é um problema intermitente que releia as correções de um daemon.

• O repo não está sendo criado fisicamente

  Mas é. A primeira vez toda vez, o repositório nulo do git em ~gitlab/repositories/username/reponame.git é criado toda vez e parece ter as permissões corretas.

• O Gitlab-shell não pode falar com o servidor da API porque A) problemas de DNS, B) ligação incorreta ip / port / interface C) não ter / ter uma barra final.

  O script de verificação diz que o acesso à API está correto.

  Eu não estou executando o nginx, então o problema de ligação ip padrão relacionado a isso é n / a.

  Eu tentei os dois *:8080 e 127.0.0.1:8080 para o valor de escuta em unicorn.yml .

  Além disso, tentei várias iterações de localhost, 127.0.0.1 e o nome de domínio totalmente qualificado (que é o DNS resolvendo bem) com e sem barras no shell.yml sem sucesso. Eu também tentei conectar isso diretamente ao servidor de unicórnio na porta 8080 em vez do host Apache SSL / proxy na porta 80. Nada parece fazer qualquer diferença. Meu certificado não é assinado por mim e funciona bem para navegadores, mas eu tentei definir self_signed_cert: true mesmo assim. Nada.

• Os caminhos git relatados estão errados, adicione o caminho totalmente qualificado da página inicial do usuário do gitlab.

  Isto parece ser uma sugestão legítima se o gitlab-shell não está fazendo algum negócio de macaco para corrigir isso, mas eu tentei mudar git remote add origin gitlab@server:username/reponame.git para '' git remote add origin gitlab @ servidor: repositories / username / reponame. git 'sem sucesso. O mesmo erro.

Esta parece ser a ladainha de soluções sugeridas, mas nenhuma delas parece correta. Note que eu posso pressionar http. O prompt de login aceita meu nome de usuário e senha do ldap e aceita um push. Este é apenas um problema ao tentar usar o SSH. Testando apenas a parte de login do ssh com ssh -T gitlab@server funciona bem.

O que mais poderia estar causando esse erro?

Como se processa a depuração de tal problema no gitlab? Não parece haver nada de relevante em ~gitlab/gitlab-shell/gitlab-shell.log . Onde uma mensagem de erro mais informativa seria encontrada?

    

Answer 1

Tenho certeza que você tem um problema de configuração entre o SSH e o sistema devido a essa mensagem de depuração SSH:

client_input_channel_req: channel 0 rtype [email protected] reply 0

Você recebe esta mensagem imediatamente após uma autenticação bem-sucedida e nenhuma mensagem do bash, o que significa que nenhum programa foi iniciado após o login.

Assista no seu arquivo passwd se você tiver as configurações corretas para o usuário do gitlab:

gitlab:x:1011:1012:GitLab,,,:/path/to/gitlab:/bin/bash

Verifique se o bash não tem nada de estranho em arquivos de configurações como

• bash.bashrc
• .profile
• .bashrc

Depois, suba para o nível superior: Gitlab-shell Verifique se o /path/to/gitlab/.ssh/authorized_keys tem a configuração abaixo:

command="/path/to/gitlab/gitlab-shell/bin/gitlab-shell key-2",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa A...

com / caminho / para / gitlab / gitlab-shell / bin / gitlab-shell de propriedade do usuário e executável do gitlab.

Você pode ter certeza de que o gitlab-shell está totalmente operacional ativando o comando:

# /path/to/gitlab-shell/bin/gitlab-shell
Welcome to GitLab, Anonymous!

Se o login remoto estiver realmente funcionando e conectado corretamente ao gitlab-shell, você deverá receber a mesma mensagem de boas-vindas (mas correspondente ao usuário cuja chave ssh você usou para efetuar login) antes de descartá-lo se você tentar efetuar login remotamente.

$ ssh gitlab@server
Welcome to GitLab, <your user's full name>!
Connection to <server> closed.

Nenhuma mensagem aqui indica que o ssh não está conectando você ao gitlab.

Finalmente, verifique sua configuração do gitlab-shell (config.yml) e verifique se:

http_settings:
    # trailing slash is important
    gitlab_url: "https://remote_server/"
    ca_file: /path/to/webserver/certificate.crt

e, eventualmente:

    self_signed_cert: false

    

Answer 2

Eu tive esse mesmo problema e depois de vários dias pesquisando e pesquisando sobre o Stack Overflow, finalmente encontrei meu problema. Eu queria ter isso por escrito conectado ao Gitlab apenas no caso de alguém ter o mesmo problema.

Encontrei minha solução aqui: link

Estou no Windows e o problema foi que o Git Bash estava tentando obter o local da chave SSH do plink.exe, que é instalado com o Putty.

A solução foi excluir a variável de ambiente GIT_SSH. Então tudo funcionou.

Espero que isso ajude alguém lá fora.