Gitolite3 falha na informação do SSH

Question

Eu instalei o gitolite3 do repositório EPEL para o Centos6.4. Havia uma série de coisas que eu não gostava, então resolvi mudá-las. Primeiro, criei um usuário e um grupo adicionais chamado 'git' para se distanciar do obscuro usuário gitolite3. Em segundo lugar, usei uma pasta personalizada / Servidor / Projetos em vez de / var / lib / gitolite3. Eu me certifiquei de que a propriedade e as permissões fossem as mesmas.

A configuração também foi feita sem problemas (su - git, então gitolite3 setup with admin client key).

Normalmente, em uma máquina cliente, o comando ssh git@myserver info geraria um bom retorno simples de gitolite listando os repositórios e as permissões. Mas agora isso me dá um pedido de senha. Obviamente, o gitolite não está mais conectado à porta ssh através deste usuário, mas o bash usual é.

Eu não sou especialista em SSH, então algo deu errado ou esqueci de fazer alguma coisa. Onde devo procurar? Eu acho / usr / share / gitolite3 / gitolite3-shell é o aplicativo que o SSHD deve chamar quando uma requisição SSH com o usuário git entrar ..

    

Answer 1

O SSH não é fácil. Eu resolvi isso sozinho, mas não era óbvio. Foi principalmente um problema do SELinux, mas descobri que eu também não tinha configurado o pubkey corretamente.

Primeiro, eu (re) criei o pubkey (admin.pub) para o computador local que iria administrar o servidor gitolite, copiei para a pasta home do usuário git do servidor, re-execute (sob o usuário git em sua pasta home ) a configuração do gitolito com esse pubkey. Uma observação aqui é que meu computador local é o windows com msys-git, tornando o problema não fácil.

# su - git
$ cd /Server/Projects
$ gitolite setup --pubkey admin.pub

.. Isso resolveu o problema do pubkey. O selinux foi uma curva de aprendizado maior, mas essencialmente você perde todos os labellings de contexto originais da pasta / var / lib / gitolite3 quando você acabou de copiar. Para restaurar as rotulagens (com semanage), você referencia as mesmas rotulagens (com o sinalizador -e) como na pasta original, para onde você definiu a pasta gitolite atual. Como isso só é adicionado aos contextos de arquivo selinux existentes, você também precisa restaurá-los nos contextos de arquivos selinux. O pithole final é usar caminhos absolutos, não caminhos relativos. Você pode ver o que você fez com o comando ll:

# semanage fcontext -a -e /var/lib/gitolite3 /Server/Projects
# restorecon -R /Server/Projects
# ll -aZ

Agora, na sua máquina local, experimente tudo com o comando abaixo do computador em que o pubkey estava vindo, funcionou para mim. Note que eu não sabia que ssh git@unclefloserver info só retornaria uma boa saída de informações de repositório gitolite3 se o servidor realmente tivesse o pubkey da combinação de usuário / computador solicitante. Eu também não entendi este conceito um pouco, e eu estava tentando isso de um computador diferente.

> git clone git@server:gitolite-admin

Um grande obrigado a @Etan Reisner por manter a pressão.