Eu tenho que rodar um script remotamente em várias máquinas Fedora através de ssh . Como o script requer privilégios root , eu faço:
$ ssh me@remost_host "sudo touch test_sudo" #just a simple example
sudo: no tty present and no askpass program specified
As máquinas remotas são configuradas de tal forma que a senha para o sudo é never solicitada.
Para o erro acima, a correção mais comum é alocar um pseudo-terminal com a opção -t em ssh:
$ ssh -t me@remost_host "sudo touch test_sudo"
sudo: no tty present and no askpass program specified
Vamos tentar forçar essa alocação com -t -t :
$ ssh -t -t me@remost_host "sudo touch test_sudo"
sudo: no tty present and no askpass program specified
Não, não funciona.
Em /etc/sudoers , claro que tenho esta linha:
#Defaults requiretty
... mas não consigo manualmente alterá-lo em dezenas de máquinas remotas.
Estou sentindo falta de algo aqui? Existe uma solução fácil?
EDITAR:
ssh me@host "sudo stat ." funciona. EDIT 2:
Executando tty em um host em que ele funciona:
$ ssh me@host_ok tty
not a tty
$ ssh -t me@host_ok tty
/dev/pts/12
Connection to host_ok closed.
$ ssh -t -t me@host_ok tty
/dev/pts/12
Connection to host_ok closed.
Agora em um host em que não funciona:
$ ssh me@host_ko tty
not a tty
$ ssh -t me@host_ko tty
not a tty
Connection to host_ko closed.
$ ssh -t -t me@host_ko tty
not a tty
Connection to host_ko closed.
EDIT 3 Permissões em / dev / tty * em uma máquina onde o acima não funcionou:
$ stat /dev/tty*
File: '/dev/tty'
Size: 0 Blocks: 0 IO Block: 4096 character special file
Device: fd02h/64770d Inode: 17089401 Links: 1 Device type: 5,0
Access: (0666/crw-rw-rw-) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2013-12-11 11:44:01.000000000 +0000
Modify: 2013-12-11 11:44:01.000000000 +0000
Change: 2014-01-20 15:43:36.000000000 +0000
EDIT 4
Ok, então no /var/log/ eu tenho o seguinte:
$ ls /var/log
btmp lastlog maillog messages secure spooler sudo tallylog wtmp yum.log
Eu tentei com messages e secure , mas eles estão vazios. sudo , por outro lado, contém algo ... o único problema é que ele exibe a mesma mensagem de log se eu usar -t , -t -t ou nada:
Jun 4 17:38:52 : my_username : no tty present and no askpass program
specified ; TTY=unknown ; PWD=/home/my_username ; USER=root ;
COMMAND=/usr/bin/stat .
tente isto:
ssh root@remote_host "sed -ibak s/requiretty/\!requiretty/ /etc/sudoers"
OR melhor ainda:
echo 'Defaults:me !requiretty' > me
scp me root@remote:/etc/sudoers.d/
ssh me@remote whatever
* um login de tempo w / root é exigido embora *
Gostaria de escrever um script para fazer o que você precisa (por exemplo, do_stuff.sh ) e, em seguida, executá-lo da seguinte forma:
ssh me@remote_host < do_stuff.sh
Você pode precisar de um ssh -t , mas isso efetivamente executa o script do_stuff.sh remotamente sem copiá-lo para os servidores remotos.
Eu tive o mesmo problema ao executar comandos sudo através do agente zabbix. Para resolver o meu problema, coloquei o seguinte arquivo no diretório sudoers.d .
# zabbix-specific additions to sudoers file
Cmnd_Alias ZABBIXCMDS = /usr/local/sbin/zabbix_user_*, /usr/local/sbin/zabbix_discovery_*
zabbix ALL=(ALL) NOPASSWD: ZABBIXCMDS
Defaults!ZABBIXCMDS !requiretty
Esse padrão deve cuidar de suas necessidades. Não é específico do Zabbix, então adapte-o ao seu uso - todas as peças estão aqui.
Em primeiro lugar, acho que você provavelmente está lidando com as coisas da maneira errada.
Se você está executando dezenas de máquinas remotas e precisando fazer coisas semelhantes em muitas delas, e se preocupando em não conseguir fazer alterações de configuração manualmente nelas, então parece que é hora de você entrar em usar o gerenciamento de configuração. Por exemplo, Puppet ou Chef são as opções mais padrão. Ou talvez Ansible, que tem menos instalação para fazer nas máquinas de destino. O Ansible é o mais provável de ter o mesmo problema.
Se você quiser continuar com sua abordagem atual, procure usar o dsh para enviar o comando para uma lista de máquinas. Provavelmente não ajudará no problema do sudo.
Isso disse ...
Você diz que "As máquinas remotas são configuradas de tal forma que a senha para o sudo nunca é pedida", mas com certeza parece que o sudo quer pedir uma senha. Verifique novamente se você pode efetuar login nessas máquinas e, em seguida, execute o sudo e ele é executado OK, sem uma senha. Se isso funcionar, verifique se há algo diferente no ambiente após o login. Por exemplo, execute 'ssh you @ remotehost env' em hosts nos quais o sudo funciona ou não.
Para ser honesto, fico mais intrigado com o modo como o sudo está funcionando, do jeito que você diz, do que como está falhando. Você não deve usar o seguinte?
my_account ALL=(ALL) NOPASSWD: ALL
Se não é assim, então como você está organizando para não exigir uma senha?