Instalei o gitolite3 do repositório EPEL no Centos6.4. Havia uma série de coisas que eu não gostava, então comecei a mudá-las. Primeiro, criei um usuário e grupo adicional chamado 'git' para me distanciar do obscuro usuário gitolite3. Segundo, usei uma pasta personalizada /Server/Projects em vez de /var/lib/gitolite3. Certifiquei-me de que a propriedade e as permissões fossem as mesmas.
A configuração também ocorreu sem problemas (su - git e, em seguida, configuração do gitolite3 com a chave do cliente admin).
Normalmente, em uma máquina cliente, o comando ssh git@myserver infogeraria um belo retorno simples do gitolite listando os repositórios e as permissões. Mas agora me dá um pedido de senha. Obviamente, o gitolite não está mais conectado à porta ssh por meio deste usuário, mas o bash normal está.
Não sou especialista em SSH, então algo deu errado ou esqueci de fazer alguma coisa. Onde devo procurar? Acho que /usr/share/gitolite3/gitolite3-shell é o aplicativo que o SSHD deve chamar quando chega uma solicitação SSH com o usuário git.
Responder1
SSH não é fácil. Eu mesmo resolvi isso, mas não era óbvio. Foi principalmente um problema do SELinux, mas descobri que também não havia configurado o pubkey corretamente.
Primeiro, eu (re)criei o pubkey (admin.pub) para o computador local que iria administrar o servidor gitolite, copiei-o para a pasta inicial do usuário git do servidor, executei novamente (sob o usuário git em sua pasta pessoal) o gitolite configure com esse pubkey. Uma observação aqui é que meu computador local é Windows com msys-git, tornando o problema difí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 todas as rotulações de contexto da pasta /var/lib/gitolite3 originais quando você apenas copia. Para restaurar os rótulos (com semanage), você faz referência aos mesmos rótulos (com o sinalizador -e) da pasta original, para onde você definiu a pasta gitolite atual. Como isso apenas aumenta os contextos de arquivo selinux existentes, você também precisa restaurá-los a partir dos contextos de arquivo selinux. O buraco final é usar caminhos absolutos, não caminhos relativos. Você pode ver o que 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 de onde veio o pubkey, funcionou para mim. Observe que eu não sabia que isso ssh git@unclefloserver infosó retornaria uma boa saída de informações do repositório gitolite3 se o servidor realmente tivesse a chave pública da combinação usuário/computador solicitante. Também não consegui entender um pouco esse conceito e estava tentando fazer isso em um computador diferente.
> git clone git@server:gitolite-admin
Muito obrigado a @Etan Reisner por manter a pressão.