Não é possível acessar o repositório de gitoses da máquina local. recebe "Permissão negada (publickey)".

1

Estou tentando configurar um servidor Git em um servidor Debian, mas não consigo adicionar usuários que possam acessá-lo com sucesso.

Depois de executar o gitosis-init e clonar o repositório gitosis-admin e adicionar a chave pública da máquina local no / keydir e editar o arquivo gitosis.conf, eu confirmo e envio. Assim como muitos dos tutoriais me dizem.

Confirmei que o repositório do gitosis-admin foi atualizado corretamente clonando-o em outro local e as atualizações foram feitas.

gitosis.conf

[gitosis]

[group gitosis-admin]
writable = gitosis-admin
members = saifis@debian, saifis@local

Agora, eu tento clonar gitosis-admin em um arquivo na minha máquina local, e ele dá um

Permission denied (publickey).

erro.

ssh -v gitosis @ O DebianAddress me dá

OpenSSH_5.2p1, OpenSSL 0.9.8l 5 Nov 2009
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to 192.168.xxx.xxx [192.168.xxx.xxx] port 22.
debug1: Connection established.
debug1: identity file /Users/saifis/.ssh/identity type -1
debug1: identity file /Users/saifis/.ssh/id_rsa type 1
debug1: identity file /Users/saifis/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5
debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '192.168.xxx.xxx' is known and matches the RSA host key.
debug1: Found key in /Users/saifis/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
-----------------
debug1: Trying private key: /Users/saifis/.ssh/identity
debug1: Trying private key: /Users/saifis/.ssh/id_dsa
debug1: No more authentication methods to try.
Permission denied (publickey).

Eu não acho que seja um problema relacionado à chave, já que a mesma chave pública é usada para entrar no mesmo servidor via SSH, e isso funciona bem.

Se mais informações forem necessárias, preencha-me.

--- Adicionado ---- Sobre o ~ / gitosis / .ssh / authorized_keys. Pelo que entendi, como os usuários autorizados do git acessam via SSH através da conta de gitosis, adicionar a chave pública ao authorized_keys parece a resposta certa, no entanto, no topo do arquivo, ele tem

### autogenerated by gitosis, DO NOT EDIT

não dizendo que eu deveria seguir cegamente o que quer que seja dito, mas adicionar a chave pública a authorized_keys daria a todos os usuários adicionados acesso a todo o servidor via ssh, e eu não quero dar tanto controle para apenas usuários do repositório.

Eu achava que a gitosis cuidava disso e só dava acesso quando era acessado pelos métodos do git, e não pelo acesso direto ao ssh, ou eles são adicionados às authorized_keys de qualquer maneira?

    
por Saifis 13.11.2010 / 14:28

1 resposta

1

Antes de você apertar qualquer coisa, a única chave que tem algum direito sobre a conta da gitosis é aquela que você passou para a gitosis-init. Que outras chaves tenham acesso à sua conta de usuário normal é irrelevante. Compare a chave em ~gitosis/.ssh/authorized_keys e ssh-add -L .

Gitosis funciona assim: em cada push, um hook pós-atualização é executado e a gitosis regenera authorized_keys para sua própria conta. Se não pegou sua chave, provavelmente não estava no formato que a gitosis espera. Como o gancho é pós-atualização, a atualização será aceita mesmo que seja inválida (a gitosis pode ser mais rigorosa por ter um gancho de atualização e de pós-atualização). Faça uma mudança trivial e pressione novamente a partir do host que tem a chave inicial para ver as mensagens de erro da gitosis. Adicionar a chave a authorized_keys manualmente envolve a duplicação da linha correta, substituindo o tipo de chave, dados de chave e nome de usuário.

    
por 13.11.2010 / 14:53

Tags