ssh tenta abrir /dev/tty para obter a senha, mas o sistema não permite que um usuário diferente daquele atualmente conectado no terminal faça isso. Devido a isso, o ssh não pode ler a senha.
Eu tenho 2 usuários no meu servidor debian, gooduser e root .
O comando my_cmd solicita uma senha (conecta-se a um servidor ssh).
Quando executo my_cmd as gooduser , tudo funciona como esperado:
gooduser@debian:/mydir$ my_cmd
[email protected]'s password:
Permission denied, please try again.
[email protected]'s password:
Permission denied, please try again.
[email protected]'s password:
Permission denied (publickey,password).
fatal: The remote end hung up unexpectedly
gooduser@debian:/mydir$
Acima, ignorei os prompts de senha pressionando enter três vezes. Por que, eu vou te dizer em breve.
Quando estou logado como root , no entanto, tento executar my_cmd como usuário gooduser (preciso fazer isso, para que todos os arquivos criados sejam de propriedade de myuser ). No entanto, ele não me pede uma senha, nem mesmo uma vez, e funciona como se eu tivesse pressionado enter três vezes, exceto que eu não fiz (as mensagens de "Permissão negada" são as mesmas acima):
root@debian:/mydir# su - gooduser -c "cd $PWD; my_cmd"
Permission denied, please try again.
Permission denied, please try again.
Permission denied (publickey,password).
fatal: The remote end hung up unexpectedly
root@debian:/mydir#
Por que isso acontece? Por que su ignora os prompts de senha? Ou, mais precisamente, por que parece pressionar entrar em meu nome? Mais importante, como posso resolver isso?
(Eu sei que eu poderia configurar chaves ssh para login sem senha e talvez seja o que eu vou fazer, mas eu gostaria de saber qual é a questão mais profunda aqui).
ssh tenta abrir /dev/tty para obter a senha, mas o sistema não permite que um usuário diferente daquele atualmente conectado no terminal faça isso. Devido a isso, o ssh não pode ler a senha.
Acabei usando sudo :
sudo -i -u gooduser -H bash -c "cd $PWD; my_cmd"
Usando esse comando, fui solicitada a senha como esperado. -i foi necessário para que $PATH fosse configurado corretamente, caso contrário, meu comando falhou.
Por que su falha, ainda não sei. Usar su funcionou no Ubuntu 12.04, mas não funcionou no Debian (portanto, minha pergunta), então não tenho certeza se a explicação do qqx se aplica.