O SSH Agent-Forwarding funciona, mas e o sudo -u username no shell / permissions? compositor

Question

Trabalhando em um servidor remoto (A) Eu quero usar minhas chaves SSH locais para acessar um repositório em outro servidor (B) que não seja controlado por mim.

Geralmente isso funciona como um encanto.

Eu faço login como myUsername no servidor remoto (A) e posso acessar os repositórios em B bem.

O problema é que existem algumas tarefas (atualização do compositor) que precisam ser executadas por outro usuário em (A).

Este usuário não é um administrador e as pastas onde os scripts são executados são dele e só devem ser graváveis por ele e não por um grupo inteiro, então eu não posso simplesmente chmod todas as pastas para 777, 775 ou algo assim;)

O problema é que quando eu quero executar o script com: %código% com certeza não há chaves encontradas, porque elas não são encaminhadas para esse usuário.

Além disso, o shell "another_user" está definido como bin / false para complicar ainda mais as coisas !!!

Existe uma solução para isso?

Para resumir tudo: Eu quero acessar outro servidor remoto através do meu próprio servidor remoto com minhas chaves ssh locais através de sudo -u another_user composer update

Seria ótimo se alguém com mais experiência pudesse me esclarecer!

edit : eu também já tentei isso: link Mas eu acho que não vai funcionar porque o outro usuário não tem shell: (

    

Answer 1

A única maneira de fazer isso é através de um hack muito sujo. Eu não recomendo isso.

setfacl -R -m u:another_user:rwx "${SSH_AUTH_SOCK%/*}"
sudo -u another_user SSH_AUTH_SOCK="$SSH_AUTH_SOCK" composer update

A razão para isso é que suas chaves SSH são acessadas através de um soquete nomeado. Esse soquete nomeado está em um diretório de sua propriedade e não pode ser acessado por mais ninguém. A única maneira de conceder acesso ao outro usuário é alterando as permissões no soquete.
O acima faz isso através de atributos estendidos do sistema de arquivos. Se o seu sistema de arquivos /tmp não suportar ACLs, a única maneira de fazer isso é chmod o+rwx , e isso é terrivelmente inseguro.

A melhor solução é corrigir o que está impedindo você de executar esse comando como seu próprio usuário.

    

Answer 2

Você pode querer usar su username (super usuário), ele será executado como aquele usuário vs sudo. Isso ajuda um pouco: (não tenho certeza se há outro em unixstackexchange) link

    

Answer 3

Em um, tente ssh other_user@localhost . Em teoria, isso deveria encaminhar sua conexão ssh-agent novamente, permitindo que outro usuário a usasse. No entanto, isso ainda não funcionará com /bin/false como o shell de other_user.

Eu não acho que não há maneira de privilégios de root para ignorar que um shell restrito (nem deveria existir).

De man su :

If the target user has a restricted shell (i.e. the shell field of this user's entry in /etc/passwd is not listed in /etc/shells), then the --shell option or the $SHELL environment variable won't be taken into account, unless su is called by root.