encaminhamento ssh-agent e sudo para outro usuário

Se eu tiver um servidor A no qual posso fazer login com minha chave ssh e tiver a capacidade de "sudo su - otheruser", perco o encaminhamento de chave, porque as variáveis ​​env são removidas e o soquete é legível apenas pelo meu usuário original. Existe uma maneira de conectar o encaminhamento de chave através do "sudo su - otheruser", para que eu possa fazer coisas em um servidor B com a minha chave encaminhada (git clone e rsync no meu caso)?

A única maneira em que consigo pensar é em adicionar minha chave às chaves_autorizadas_de_usuário e ao "ssh otheruser @ localhost", mas isso é complicado de fazer em todas as combinações de usuários e servidores que eu possa ter.

Em resumo:

$ sudo -HE ssh user@host
(success)
$ sudo -HE -u otheruser ssh user@host
Permission denied (publickey). 

Como você mencionou, as variáveis ​​de ambiente são removidas por sudo, por razões de segurança.

Mas, felizmente, sudoé bastante configurável: você pode dizer com precisão em quais variáveis ​​de ambiente deseja manter, graças à env_keepopção de configuração /etc/sudoers.

Para encaminhamento de agente, você precisa manter a SSH_AUTH_SOCKvariável de ambiente. Para fazer isso, basta editar seu /etc/sudoersarquivo de configuração (sempre usando visudo) e defina a env_keepopção para os usuários apropriados. Se você deseja que esta opção seja definida para todos os usuários, use a Defaultslinha como esta:

Defaults    env_keep+=SSH_AUTH_SOCK

man sudoers para mais detalhes.

Agora você deve conseguir fazer algo assim ( user1a chave pública fornecida está presente em ~/.ssh/authorized_keysin user1@serverAe user2@serverB, e serverAo /etc/sudoersarquivo está configurado conforme indicado acima):

user1@mymachine> eval `ssh-agent`  # starts ssh-agent
user1@mymachine> ssh-add           # add user1's key to agent (requires pwd)
user1@mymachine> ssh -A serverA    # no pwd required + agent forwarding activated
user1@serverA> sudo su - user2     # sudo keeps agent forwarding active :-)
user2@serverA> ssh serverB         # goto user2@serverB w/o typing pwd again...
user2@serverB>                     # ...because forwarding still works

sudo -E -s

• -E preservará o meio ambiente
• -s executa um comando, o padrão é um shell

Isso fornecerá um shell raiz com as chaves originais ainda carregadas.

Permita que outro usuário acesse o $SSH_AUTH_SOCKarquivo e seu diretório, por exemplo, pela ACL correta, antes de mudar para eles. O exemplo assume Defaults:user env_keep += SSH_AUTH_SOCKna /etc/sudoersmáquina host:

$ ssh -A user@host
user@host$ setfacl -m otheruser:x   $(dirname "$SSH_AUTH_SOCK")
user@host$ setfacl -m otheruser:rwx "$SSH_AUTH_SOCK"
user@host$ sudo su - otheruser
otheruser@host$ ssh server
otheruser@server$

Mais seguro e funciona também para usuários não root ;-)

Eu descobri que isso também funciona.

sudo su -l -c "export SSH_AUTH_SOCK=$SSH_AUTH_SOCK; bash"

Como outros observaram, isso não funcionará se o usuário para o qual você está mudando não tiver permissões de leitura em $ SSH_AUTH_SOCK (que é praticamente qualquer usuário além do root). Você pode contornar isso definindo $ SSH_AUTH_SOCK e o diretório em que está para ter as permissões 777.

chmod 777 -R `dirname $SSH_AUTH_SOCK`
sudo su otheruser -l -c "export SSH_AUTH_SOCK=$SSH_AUTH_SOCK; bash"

Isso é bastante arriscado. Você basicamente concede permissão a todos os outros usuários do sistema para usar o seu Agente SSH (até você sair). Você também pode definir o grupo e alterar as permissões para 770, o que poderia ser mais seguro. No entanto, quando tentei mudar de grupo, recebi "Operação não permitida".

Se você estiver autorizado sudo su - $USER, provavelmente terá um bom argumento para ter permissão para fazer isso ssh -AY $USER@localhost, com sua chave pública válida no diretório inicial do $ USER. Em seguida, seu encaminhamento de autenticação será realizado com você.

Você sempre pode apenas ssh no localhost com encaminhamento de agente, em vez de usar o sudo:

ssh -A otheruser@localhost

A desvantagem é que você precisa fazer login novamente, mas se você o estiver usando na guia screen / tmux, isso é apenas um esforço de uma vez; no entanto, se você se desconectar do servidor, o soquete (é claro) será quebrado novamente . Portanto, não é o ideal se você não pode manter sua sessão screen / tmux aberta o tempo todo (no entanto, você pode atualizar manualmente seu SSH_AUTH_SOCKenv var se você for legal).

Observe também que, ao usar o encaminhamento ssh, o root sempre pode acessar seu soquete e usar sua autenticação ssh (desde que você esteja logado com o encaminhamento ssh). Portanto, verifique se você pode confiar no root.

Não use sudo su - USER, mas sim sudo -i -u USER. Funciona para mim!

Combinando informações das outras respostas, vim com isso:

user=app
setfacl -m $user:x $(dirname "$SSH_AUTH_SOCK")
setfacl -m $user:rwx "$SSH_AUTH_SOCK"
sudo SSH_AUTH_SOCK="$SSH_AUTH_SOCK" -u $user -i

Eu gosto disso porque não preciso editar o sudoersarquivo.

Testado no Ubuntu 14.04 (tive que instalar o aclpacote).

Eu acho que há um problema com a -opção (traço) depois suem seu comando:

sudo su - otheruser

Se você ler a página de manual do su , poderá achar que a opção -, -l, --logininicia o ambiente do shell como shell de login. Este será o ambiente, otheruserindependentemente das variáveis ​​env em que você executa su.

Simplificando, o traço prejudicará tudo o que você passou sudo.

Em vez disso, você deve tentar este comando:

sudo -E su otheruser

Como o @ joao-costa apontou, -Epreservará todas as variáveis ​​no ambiente em que você executou sudo. Então, sem o traço, suusará esse ambiente diretamente.

Infelizmente, quando você faz o su para outro usuário (ou mesmo usa o sudo), perde a capacidade de usar suas chaves encaminhadas. Este é um recurso de segurança: você não deseja que usuários aleatórios se conectem ao seu ssh-agent e usem suas chaves :)

O método "ssh -Ay $ {USER} @localhost" é um pouco complicado (e conforme observado no meu comentário sobre a resposta de David propenso a falhas), mas é provavelmente o melhor que você pode fazer.