1

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 .
Improve this question
15
  • 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? Commented 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. Commented 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). Commented Jun 2, 2014 at 19:29
  • 2
    It's past time to puppetize these servers. Commented 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. Commented Jun 3, 2014 at 10:24

4 Answers 4

Reset to default
1

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 *

Improve this answer
9
  • Providing me is a root account. Commented 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... Commented 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 Commented Jun 2, 2014 at 16:52
  • 1
    Use cssh to work interactively on a large number of machines. Commented 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. Commented Jun 4, 2014 at 8:15
0

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.

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

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.

Improve this answer
3
  • Oh ok, but zabbix isn't running on those machines... :/ Commented 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. Commented 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. Commented Jun 4, 2014 at 4:30
0

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?

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.