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

4

Eu posso clonar um projeto da seguinte forma:

$ git clone [email protected]:root/myproject.git ~/bla

Mas agora desejo cloná-lo em /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? Eu estou sendo perguntado por uma senha? Não devemos precisar de senhas fedidas!

Estou obviamente 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 foi alterar temporariamente as permissões da pasta ou primeiro cloná-la em algum lugar que eu tenha acesso e, em seguida, movê-la usando sudo, mas gostaria de aprender o caminho certo para fazê-lo.

Então ... Como eu uso o git com as chaves ssh do meu usuário normal, mas as permissões do arquivo sudo?

    
por user1032531 20.11.2017 / 17:14

2 respostas

2

Se você tem um agente ssh em execução, faça:

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

Isso basicamente diz ao comando git iniciado por root (ou o comando ssh iniciado pelo comando git ) para usar seu ssh agent (como se conectar a ele, que root deve poder como tem todo direito).

Se você não tem um agente ssh em execução, você pode começar um com:

eval "$(ssh-agent)"

(e adicione chaves a ele conforme necessário com ssh-add ).

Como alternativa, você pode usar

sudo -E git clone...

Para passar todas as variáveis de ambiente em sudo , não apenas $SSH_AUTH_SOCK .

Eu não recebi a sugestão do @ NgOon-Ee no comentário para adicionar $SSH_AUTH_SOCK à lista env_keep . Em geral, você não deseja poluir o ambiente de root , pois esse é o usuário no qual você inicia os serviços. Por exemplo, sudo sshd para iniciar um serviço sshd significaria que todas as ssh sessões iniciadas através desse serviço herdariam seu $SSH_AUTH_SOCK , poluindo o ambiente dos usuários com algo que eles não podem e não deveriam usar. Mesmo para outros usuários de destino do que root , transmitir essa variável não faria sentido, pois o usuário de destino não poderia fazer uso desse agente de autenticação.

Agora, isso só atende à autenticação de chaves. Se você também quisesse que root herdasse suas configurações em ~/.ssh/config , você não poderia fazer isso com ssh de variáveis de ambiente, mas poderia fazer isso com git de variáveis de ambiente. Por exemplo, definindo uma função sugit 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 o comando ssh que usa seu arquivo de configuração ssh e agente e nome de usuário em vez de root.

Ou talvez ainda melhor, diga git para executar ssh como o usuário original:

sugit() {
  sudo "GIT_SSH_COMMAND=
    exec sudo -Hu $LOGNAME SSH_AUTH_SOCK='$SSH_AUTH_SOCK' ssh" git "$@"
}
    
por 20.11.2017 / 18:16
0

Permissões de arquivo (ou soquete) podem ser complicadas se os arquivos de chaves (ou soquete) não puderem ser lidos pelo usuário sudo executado como. Isso definitivamente inclui root se os arquivos residem em um compartilhamento de rede que root não tem permissão para, ou o diretório base deve ser criptografado, o que pode novamente negar root access.

Outra forma de sistemas Unix que suportam ACLs estendidas é usá-los, caso em que você pode conceder acesso de gravação adicional sobre as permissões de base 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 grupo webedit tem permissões graças ao setfacl

$ 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 sobre ACLs estendidas, por exemplo, verifique como o software de backup as manipula, etc.

    
por 21.11.2017 / 21:03