Como usar qualquer comando (como git) com chaves ssh de um usuário normal, mas com permissões de arquivo sudo

Como usar qualquer comando (como git) com chaves ssh de um usuário normal, mas com permissões de arquivo sudo

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 sshagente em execução, faça:

sudo SSH_AUTH_SOCK="$SSH_AUTH_SOCK" git clone...

Isso basicamente informa ao gitcomando iniciado por root(ou ao sshcomando iniciado por esse gitcomando) para usar seu sshagente (como se conectar a ele, o que rootdeve 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_keeplista. Em geral, você não quer poluir rooto ambiente de , já que é com esse usuário que você inicia os serviços. Por exemplo, sudo sshdiniciar um sshdserviço significaria que todas sshas sessões iniciadas por meio desse serviço herdariam o seu $SSH_AUTH_SOCKambiente, 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 rootherdar suas configurações no seu arquivo ~/.ssh/config, não poderia fazer isso com sshvariáveis ​​de ambiente, mas poderia fazer isso com gitvariáveis ​​de ambiente. Por exemplo, definindo uma sugitfunçã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 gitpara usar um sshcomando que use seu arquivo de configuração ssh, agente e nome de usuário em vez do root.

Ou talvez ainda melhor, diga gitpara executar sshcomo 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 rootse os arquivos residem em um compartilhamento de rede rootsem permissão ou se o diretório inicial está criptografado, o que pode novamente negar rooto 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 webeditgrupo 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.

informação relacionada