%20com%20chaves%20ssh%20de%20um%20usu%C3%A1rio%20normal%2C%20mas%20com%20permiss%C3%B5es%20de%20arquivo%20sudo.png)
Posso clonar um projeto da seguinte maneira:
$ git clone [email protected]:root/myproject.git ~/bla
Mas agora desejo cloná-lo para /var/www
. Então eu tento
$ git clone [email protected]:root/myproject.git ~/var/www
Mas, infelizmente, não tenho permissão para escrever para /var/www
. Sudo para o resgate!
$ sudo git clone [email protected]:root/myproject.git ~/var/www
Cloning into 'www'...
[email protected]'s password:
O que é isso? Estou sendo solicitado a fornecer uma senha? Não deveríamos precisar de senhas fedorentas!
Obviamente estou enviando as chaves ssh do usuário root com a solicitação e, como elas não foram importadas para o repositório git, estou sendo negado. No passado, minha solução era alterar temporariamente as permissões da pasta ou primeiro cloná-la em algum lugar onde eu tivesse acesso e depois movê-la usando o sudo, mas gostaria de aprender a maneira correta de fazer isso.
Então... Como uso o git com as chaves ssh do meu usuário normal, mas com permissões de arquivo sudo?
Responder1
Se você tiver um ssh
agente em execução, faça:
sudo SSH_AUTH_SOCK="$SSH_AUTH_SOCK" git clone...
Isso basicamente informa ao git
comando iniciado por root
(ou ao ssh
comando iniciado por esse git
comando) para usar seu ssh
agente (como se conectar a ele, o que root
deve ser possível, pois tem todo o direito).
Se você não tiver um agente ssh em execução, poderá iniciar um antecipadamente com:
eval "$(ssh-agent)"
(e adicione chaves conforme necessário com ssh-add
).
Alternativamente, você pode usar
sudo -E git clone...
Passartodovariável de ambiente em sudo
, não apenas $SSH_AUTH_SOCK
.
Eu poderianãorecebi a sugestão de @ NgOon-Ee no comentário para adicionar $SSH_AUTH_SOCK
à env_keep
lista. Em geral, você não quer poluir root
o ambiente de , já que é com esse usuário que você inicia os serviços. Por exemplo, sudo sshd
iniciar um sshd
serviço significaria que todas ssh
as sessões iniciadas por meio desse serviço herdariam o seu $SSH_AUTH_SOCK
ambiente, poluindo o ambiente dos usuários com algo que eles não podem e não devem usar. Mesmo para outros usuários-alvo além de root
, passar essa variável não faria sentido, pois o usuário-alvo não poderia fazer uso desse agente de autenticação.
Agora, isso aborda apenas a autenticação de chave. Se você também quisesse root
herdar suas configurações no seu arquivo ~/.ssh/config
, não poderia fazer isso com ssh
variáveis de ambiente, mas poderia fazer isso com git
variáveis de ambiente. Por exemplo, definindo uma sugit
função como:
sugit() {
sudo "GIT_SSH_COMMAND=
exec ssh -o IdentityAgent='$SSH_AUTH_SOCK' \
-o User=$LOGNAME \
-F ~$LOGNAME/.ssh/config" git "$@"
}
Ou seja, diga git
para usar um ssh
comando que use seu arquivo de configuração ssh, agente e nome de usuário em vez do root.
Ou talvez ainda melhor, diga git
para executar ssh
como usuário original:
sugit() {
sudo "GIT_SSH_COMMAND=
exec sudo -Hu $LOGNAME SSH_AUTH_SOCK='$SSH_AUTH_SOCK' ssh" git "$@"
}
Responder2
As permissões de arquivo (ou soquete) podem ser complicadas se os arquivos de chave (ou soquete) não puderem ser lidos pelo usuário sudo
. Definitivamente, isso inclui root
se os arquivos residem em um compartilhamento de rede root
sem permissão ou se o diretório inicial está criptografado, o que pode novamente negar root
o acesso.
Outra maneira em sistemas Unix que suportam ACLs estendidas é usá-las; nesse caso, você pode conceder acesso de gravação adicional além das permissões básicas usuais:
$ sudo chown apache:www /var/www/html
$ sudo chmod g+s /var/www/html
$ sudo setfacl -m g:webedit:rwx /var/www/html
$ groups
jdoe webedit
$ ls -ld /var/www/html
drwxrwsr-x+ 4 apache www 25 Nov 21 19:42 /var/www/html
$
mas o webedit
grupo tem permissões graças aosetfacl
$ git clone ~/repo /var/www/html
Cloning into '/var/www/html'...
done.
$ ls -al /var/www/html
total 0
drwxrwsr-x+ 4 apache www 25 Nov 21 19:42 .
drwxr-xr-x 4 root root 31 Oct 19 20:39 ..
drwxrwsr-x 3 jdoe www 14 Nov 21 19:42 a
drwxrwsr-x 8 jdoe www 152 Nov 21 19:42 .git
$
no entanto, existem várias dicas em torno de ACLs estendidas, por exemplo, verifique como seu software de backup as trata, etc.