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?


  • 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
Connection to host_ok closed.

$ ssh -t -t me@host_ok tty
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


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 .
  • 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, 2014 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.
    – user9517
    Jun 2, 2014 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). Jun 2, 2014 at 19:29
  • 2
    It's past time to puppetize these servers. Jun 3, 2014 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, 2014 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 *

  • Providing me is a root account. Jun 2, 2014 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... Jun 2, 2014 at 16:48
  • hmm... I can call sudo on those machines, but I don't have access to the root account, unfortunately Jun 2, 2014 at 16:52
  • 1
    Use cssh to work interactively on a large number of machines. Jun 3, 2014 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, 2014 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.

  • Hm. I don't understand how this could solve my problem :) Jun 2, 2014 at 16:52
  • Yeah, I don't know what you're trying to do. Can you give a more solid example?
    – ewwhite
    Jun 2, 2014 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 ." Jun 3, 2014 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_*
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.

  • Oh ok, but zabbix isn't running on those machines... :/ Jun 3, 2014 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, 2014 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, 2014 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?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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