ssh-agent forwarding e sudo para outro usuário

Question

Se eu tiver um servidor A no qual eu possa logar com minha chave ssh e eu tenho a habilidade de "sudo su - otheruser", eu 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 que eu possa preencher o encaminhamento de chaves 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 que posso pensar é adicionar minha chave ao authorized_keys de otheruser e "ssh otheruser @ localhost", mas isso é complicado para qualquer combinação de usuário e servidor que eu possa ter.

Resumindo:

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

    

Answer 1

Como você mencionou, as variáveis de ambiente são removidas por sudo , por 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 à opção de configuração env_keep em /etc/sudoers .

Para o encaminhamento de agentes, você precisa manter a variável de ambiente SSH_AUTH_SOCK . Para isso, basta editar o arquivo de configuração /etc/sudoers (sempre usando visudo ) e definir a opção env_keep para os usuários apropriados. Se você quiser que essa opção seja definida para todos os usuários, use a linha Defaults da seguinte forma:

Defaults    env_keep+=SSH_AUTH_SOCK

man sudoers para mais detalhes.

Agora você deve poder fazer algo assim (desde que a chave pública de user1 esteja presente em ~/.ssh/authorized_keys em user1@serverA e user2@serverB , e serverA ' /etc/sudoers file seja configurado como 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

    

Answer 2

sudo -E -s

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

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

    

Answer 3

Permitir que outro usuário acesse o arquivo $SSH_AUTH_SOCK e seu diretório, por exemplo, pela ACL correta, antes de alternar para eles. O exemplo assume Defaults:user env_keep += SSH_AUTH_SOCK em /etc/sudoers na má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; -)

    

Answer 4

Eu descobri que isso também funciona.

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

Como outros notaram, 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 configurando $ SSH_AUTH_SOCK e o diretório em que ele 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ê está basicamente dando a todos os outros usuários do sistema permissão para usar seu Agente SSH (até que você efetue logout). 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 o grupo, recebi "Operação não permitida".

    

Answer 5

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

    

Answer 6

Você pode sempre apenas ssh para localhost com o encaminhamento de agentes em vez de usar o sudo:

ssh -A otheruser@localhost

A desvantagem é que você precisa efetuar login novamente, mas se você estiver usando em uma guia screen / tmux, isso é apenas um esforço de tempo, no entanto, se você se desconectar do servidor, o soquete (é claro) ser quebrado novamente. Portanto, nã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_SOCK env 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 (contanto que você esteja logado com o encaminhamento ssh). Portanto, verifique se você pode confiar na raiz.

    

Answer 7

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

    

Answer 8

Combinando informações das outras respostas, descobri 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 arquivo sudoers .

Testado no Ubuntu 14.04 (tive que instalar o pacote acl ).

    

Answer 9

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

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

    

Answer 10

Acho que há um problema com a opção - (traço) depois de su no seu comando:

sudo su - otheruser

Se você ler a página de manual do su , poderá descobrir que a opção -, -l, --login inicia o ambiente shell como shell de login. Este será o ambiente para otheruser , independentemente das variáveis de env em que você executa su .

Simplificando, o traço afetará qualquer coisa que você tenha passado de sudo .

Em vez disso, você deve tentar este comando:

sudo -E su otheruser

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