☰

encaminhamento de agente ssh e sudo para outro usuário

tag-icon • tag-icon ssh sudo forwarding ssh-agent agent
encaminhamento de agente ssh 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 removidaseo soquete só pode ser lido 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 minha chave encaminhada (git clone e rsync no meu caso)?

A única maneira que consigo pensar é adicionar minha chave às chaves_autorizadas de otheruser e "ssh otheruser@localhost", mas isso é complicado de fazer para cada combinação de usuário e servidor que eu possa ter.

Resumidamente:

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

Responder1

Como você mencionou, as variáveis ​​de ambiente são removidas sudopor motivos de segurança.

Mas felizmente sudoé bastante configurável: você pode dizer com precisão quais variáveis ​​de ambiente deseja manter graças à env_keepopção de configuração no /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 definir 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 assim:

Defaults    env_keep+=SSH_AUTH_SOCK

man sudoerspara mais detalhes.

Agora você deve ser capaz de fazer algo assim (desde que user1a chave pública de esteja presente em ~/.ssh/authorized_keyse user1@serverAe user2@serverBo serverAarquivo /etc/sudoersesteja 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

Responder2

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

Isso lhe dará um shell root com as chaves originais ainda carregadas.

Responder3

Permitiroutro usuáriopara acessar $SSH_AUTH_SOCKo arquivo 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

Responder4

Você sempre pode simplesmente usar ssh para localhost com encaminhamento de agente em vez de usar sudo:

ssh -A otheruser@localhost

A desvantagem é que você precisa fazer login novamente, mas se estiver usando-o em uma guia screen/tmux, isso será feito apenas uma vez, no entanto, se você se desconectar do servidor, o soquete (é claro) será quebrado novamente . Portanto, não é ideal se você não consegue manter sua sessão screen/tmux aberta o tempo todo (no entanto, você pode atualizar manualmente seu SSH_AUTH_SOCKenv var se estiver tudo bem).

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, certifique-se de confiar no root.

informação relacionada