Estou no servidor Ubuntu 14.04.
Estou usando o servidor da web apache, que é executado como o www-data . Eu preciso fazer git clone de um script (um web hook). Este script será executado com os privilégios de usuário www-data .
Executando git clone como usuário regular no diretório /var/www/html em que corri para problemas de permissão, o que é bom, pois quero que o usuário www-data seja capaz de escrever lá.
O usuário www-data tem seu home definido como /var/www e as chaves ssh estão em /var/www/.ssh .
Se eu correr:
sudo git clone [email protected]:user/repo.git
Funciona como esperado - a chave pública ssh do meu usuário está listada como em authorized_keys @ my.git.server.
No entanto, preciso executar a partir de um script bash e com privilégios normais.
Então copiei a chave ssh pública para o usuário www-data para o arquivo authorized_keys em my.git.server. Em teoria, isso deve significar que o usuário do www-data pode iniciar o git clone sobre o ssh, removendo a necessidade de senhas e sendo bastante seguro.
Então, para testá-lo, acho que preciso executar algo como:
sudo -u www-data -H git clone [email protected]:user/repo.git
Meu entendimento é que me permitiria assumir a identidade do usuário www-data , definir meu diretório inicial para que ~/.ssh esteja no diretório de trabalho quando o git clone over ssh for emitido .
O problema que tenho é a seguinte saída de erro quando tento executar o comando:
Cloning into 'repo'...
fatal: 'user/repo.git' does not appear to be a git repository
fatal: Could not read from remote repository.
Como eu disse, se eu corro como sudo - sem problema. Apenas quando tento executar como www-data. Parece que há um problema com o modo como o comando está sendo interpretado que obriga a ler o nome do caminho / repositório incorretamente?
Seguindo a resposta do l0b0, a saída é a seguinte:
james-c@WebHost-1:~$ sudo ssh -v [email protected] 2>&1 | grep 'identity file'
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: identity file /root/.ssh/id_ed25519-cert type -1
james-c@WebHost-1:~$ sudo -u www-data ssh -v [email protected] 2>&1 | grep 'identity file'
debug1: identity file /var/www/.ssh/id_rsa type 1
debug1: identity file /var/www/.ssh/id_rsa-cert type -1
debug1: identity file /var/www/.ssh/id_dsa type -1
debug1: identity file /var/www/.ssh/id_dsa-cert type -1
debug1: identity file /var/www/.ssh/id_ecdsa type -1
debug1: identity file /var/www/.ssh/id_ecdsa-cert type -1
debug1: identity file /var/www/.ssh/id_ed25519 type -1
debug1: identity file /var/www/.ssh/id_ed25519-cert type -1
Não sabe exatamente o que estou procurando aqui?
Encontrei o mesmo problema, parece que o ambiente é preservado ao alternar os usuários dessa maneira. Isso faz com que a configuração errada do git seja carregada, o que falha devido a problemas de permissão.
No meu caso, contornei o problema usando o seguinte comando
sudo -u deploydeputy /bin/bash -c "export HOME=/home/deploydeputy && git clone [email protected]:inventid/cdn.git /tmp/cdn"