Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have to run a script remotely on several Fedora machines through ssh. Since the script requires root priviliges, I do:

$ ssh me@remost_host "sudo touch test_sudo" #just a simple example
sudo: no tty present and no askpass program specified

The remote machines are configured in such a way that the password for sudo is never asked for. For the above error, the most common fix is to allocate a pseudo-terminal with the -t option in ssh:

$ ssh -t me@remost_host "sudo touch test_sudo"
sudo: no tty present and no askpass program specified

Let's try to force this allocation with -t -t:

$ ssh -t -t me@remost_host "sudo touch test_sudo"
sudo: no tty present and no askpass program specified

Nope, it doesn't work.

In /etc/sudoers of course I have this line:

#Defaults    requiretty

... but I can't manually change it on tens of remote machines.

Am I missing something here? Is there an easy fix?

EDIT:

  • Here is the sudoers file of a host where ssh me@host "sudo stat ." works.
  • Here is the sudoers file of a host where it doesn't work.

EDIT 2: Running tty on a host where it works:

$ 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.

Now on a host where it doesn't work:

$ 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 Permissions on /dev/tty* on a machine where the above didn't work:

$ 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, so in the /var/log/ I have the following:

$ ls /var/log 
btmp  lastlog  maillog  messages  secure  spooler  sudo  tallylog  wtmp  yum.log

I tried with messages and secure, but they are empty. sudo on the other hand contains something... the only problem being it displays the same log message whether I use -t, -t -t or nothing:

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 .
share|improve this question
    
One trick I once used for that is to dump text for the script to run remotely in a file, then execute that shell script to finally remove it. As for the password part...ssh key with local connect? –  vn. May 27 at 15:04
2  
Can you show us your (suitably redacted sudoers file(s)) I can't even force a system to act in the way you're seeing. –  Iain Jun 2 at 17:13
1  
I'm sure this method should work. Unless perhaps you're overriding the tty allocation in the ssh key. Can you provide your ~/.ssh/authorized_keys file (the one for the original user you are logging in with, not root). –  Matthew Ife Jun 2 at 19:29
2  
It's past time to puppetize these servers. –  Michael Hampton Jun 3 at 9:52
1  
I was thinking about the sshd logs - where they end up will vary depending on the syslog config. Usually /var/log/messages or /var/log/secure. However, since there's something really wrong with these systems, would it be possible for you to open a separate SSHD on a different port with lots of debugging turned on, and try connecting to that one? Use the command sshd -ddd -p 2022 to make it listen on port 2022 and with max debug. –  Jenny D Jun 3 at 10:24

4 Answers 4

try this:

ssh root@remote_host "sed -ibak s/requiretty/\!requiretty/ /etc/sudoers"

OR better yet this:

echo 'Defaults:me !requiretty' > me
scp me root@remote:/etc/sudoers.d/
ssh me@remote whatever

* one time login w/ root is required though *

share|improve this answer
    
Providing me is a root account. –  Matthew Ife Jun 2 at 16:48
    
Ok, but that will just grab the incriminated line from the sudoers file, right? I was just wondering if there was a way around this restriction... –  Ricky Robinson Jun 2 at 16:48
    
hmm... I can call sudo on those machines, but I don't have access to the root account, unfortunately –  Ricky Robinson Jun 2 at 16:52
1  
Use cssh to work interactively on a large number of machines. –  Felix Frank Jun 3 at 8:57
1  
Actually, the problem is that sshd doesn't allow him to create a pseudo-tty. It's not just sudo that will have a problem with this. Removing the tty requirement from sudo will fix the immediate issue but not the underlying problem. –  Jenny D Jun 4 at 8:15

I would write a script to do what you need (e.g. do_stuff.sh), then execute it like:

ssh me@remote_host < do_stuff.sh

You may need an ssh -t in there, but this effectively executes the do_stuff.sh script remotely without actually copying it to the remote servers.

share|improve this answer
    
Hm. I don't understand how this could solve my problem :) –  Ricky Robinson Jun 2 at 16:52
    
Yeah, I don't know what you're trying to do. Can you give a more solid example? –  ewwhite Jun 2 at 16:54
    
I just need to run something needing sudo through ssh. On half of the machines I have this seems to be disabled, even if I add the -t or -t -t options to ssh. For example: ssh me@host "sudo stat ." –  Ricky Robinson Jun 3 at 9:04

I had the same problem running sudo commands via the zabbix agent. To solve my problem, I dropped the following file into the sudoers.d directory.

# 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

This pattern should take care of your needs. It's not specific to Zabbix so just adapt it to your use - all the pieces are here.

share|improve this answer
    
Oh ok, but zabbix isn't running on those machines... :/ –  Ricky Robinson Jun 3 at 9:03
1  
This solution is not unique to Zabbix. The key is in the NOPASSWD part so that sudo will not ask you for a password before running the command. That's the problem you are running in to. Of course, you will still need to edit the sudoers file manually or add a file to sudoers.d manually for all your servers. –  Ladadadada Jun 3 at 10:45
    
Yes - it's just a pattern. Deploy a similar file (tailored to your environment) via scp, puppet, salt, whatever you like. –  MikeyB Jun 4 at 4:30

Firstly, I think you're probably tackling things the wrong way.

  • If you're running tens of remote machines, and needing to do similar things on many of them, and worrying about not being able to make config changes manually on them, then it sounds like it's time for you to get into using configuration management. Eg Puppet or Chef are the more standard options. Or maybe Ansible, which has less installation to do on the target machines. Ansible's the most likely to run into the same problem though.

  • If you want to continue with your current approach, look at using dsh to send the command to a list of machines. Probably won't help with the sudo issue though.

That said...

You say that "The remote machines are configured in such a way that the password for sudo is never asked for", but it sure looks like sudo wants to ask for a password. Check again that you can log in to those machines, then run sudo, and it runs OK, without a password. If that works, then check if there's something different in the environment after you log in. eg run 'ssh you@remotehost env' against hosts where sudo does and doesn't work.

To be honest, I'm more puzzled by how sudo is working where you say it does than by how it's failing. Shouldn't you use the following?

my_account ALL=(ALL) NOPASSWD: ALL

If not like that, then how are you arranging not to require a password?

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.