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 .
Ricky Robinson
  • 205
  • 1
  • 4
  • 18
  • 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 '14 at 15:04
  • Oh, so do you mean that (in that example above) I should write "sudo touch test_sudo" to a remote file and that run that file? I forgot to say that I don't have to specify any password when typing `sudo`. – Ricky Robinson May 27 '14 at 17:34
  • It seemed like a good idea, but it doesn't work :( – Ricky Robinson Jun 02 '14 at 15:57
  • 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 02 '14 at 17:13
  • I cannot reproduce the missing tty error when running with `-t`. What do you get, if you run `ssh -t me@remost_host tty`? – kasperd Jun 02 '14 at 17:58
  • 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 02 '14 at 19:29
  • Ok, I updated my question with a link to the sudoers file and the output of `tty`. Unfortunately I don't have any `~/.ssh/authorized_keys` on those machines. It's an experimental testbed (planetlab), it must be managed in a different way than expected. – Ricky Robinson Jun 03 '14 at 09:01
  • 2
    It's past time to puppetize these servers. – Michael Hampton Jun 03 '14 at 09:52
  • Just checking - you don't have any type of chroot enabled for ssh, do you? – Jenny D Jun 03 '14 at 09:57
  • Also - what do the logs on the servers where it doesn't work say? What are the permissions on /dev/tty*? Do you get a tty when you ssh in to start a shell instead of just to run a comand? – Jenny D Jun 03 '14 at 09:58
  • Yes, when I ssh to start a shell everything works as expected. Could you please be more specific about 1) which logs to check 2) how to check if chroot is enabled? :) Thanks a lot – Ricky Robinson Jun 03 '14 at 10:07
  • I just added the output of `stat /dev/tty*`, hoping it's what you were asking for :) – Ricky Robinson Jun 03 '14 at 10:09
  • 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 03 '14 at 10:24
  • Unfortunately those logs are empty and I cannot seem to be able to find where `sshd` is (I might not even have access to it)... I think I can give up here :) Thanks you for your time, Jenny D. :) – Ricky Robinson Jun 05 '14 at 11:26
  • @RickyRobinson you can always add `*.* /var/log/all.log` to your (r)syslog(d). – alexus Jun 06 '14 at 19:45

4 Answers4

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 *

alexus
  • 12,342
  • 27
  • 115
  • 173
  • Providing `me` is a root account. – Matthew Ife Jun 02 '14 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 02 '14 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 02 '14 at 16:52
  • I'm talking about around 80 machines... :/ – Ricky Robinson Jun 02 '14 at 16:54
  • I'd script it... – alexus Jun 02 '14 at 16:56
  • sure, but the problem here is that on half of these machines I cannot run through ssh any command along with sudo, it is simply disabled. I would have to ssh to them and interactively do the above command, right? – Ricky Robinson Jun 02 '14 at 16:59
  • if `sudo` is disabled, then this error wouldn't popup) this error is sudo related.. the buttom line you need to disable `requiretty` for single user or for everyone, how you do it it's up to you) – alexus Jun 02 '14 at 17:01
  • 1
    Use `cssh` to work interactively on a large number of machines. – Felix Frank Jun 03 '14 at 08: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 04 '14 at 08: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.

ewwhite
  • 194,921
  • 91
  • 434
  • 799
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.

MikeyB
  • 38,725
  • 10
  • 102
  • 186
  • Oh ok, but zabbix isn't running on those machines... :/ – Ricky Robinson Jun 03 '14 at 09: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 03 '14 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 04 '14 at 04: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?

mc0e
  • 5,786
  • 17
  • 31