18

I'm trying to login to a ssh server and to execute something like:

ssh user@domain.com 'sudo echo "foobar"'

Unfortunately I'm getting an error:

sudo: no tty present and no askpass program specified

Google told me to either set the environment variable SSH_ASKPASS or to set askpass in the sudoers file. My remote machine is running on Debian 6 and I've installed the packages ssh-askpass and ssh-askpass-gnome and my sudoers file looks like this:

Defaults        env_reset
Defaults        askpass=/usr/bin/ssh-askpass

# User privilege specification
root    ALL=(ALL) ALL
user    ALL=(ALL) ALL

Can someone tell what I'm doing wrong and how to do it better.

tshepang
  • 12,111
  • 21
  • 91
  • 136
jan
  • 650
  • 1
  • 6
  • 17

5 Answers5

20

There are two ways to get rid of this error message. The easy way is to provide a pseudo terminal for the remote sudo process. You can do this with the option -t:

ssh -t user@domain.com 'sudo echo "foobar"'
nosid
  • 48,932
  • 13
  • 112
  • 139
  • 1
    @bradley.ayers: The problem is that `sudo` wants to read a password from a tty. Either you provide a tty for sudo or you avoid the password check in sudo. The latter is more difficult if you want to get security right. – nosid Sep 25 '12 at 06:48
4

Rather than allocating a TTY, or setting a password that can be seen in the command line, do something like this.

Create a shell file that echo's out your password like:

#!/bin/bash

echo "mypassword"

then copy that to the node you want using scp like this:

scp SudoPass.sh somesystem:~/bin

Then when you ssh do the following:

ssh somesystem "export SUDO_ASKPASS=~/bin/SudoPass.sh;sudo -A command -parameter"
Ahmed Salman Tahir
  • 1,783
  • 1
  • 17
  • 26
Michael
  • 49
  • 1
  • 3
  • how about `export SUDO_ASKPASS='echo "mypassword"'; sudo whatever_command` ? I have not tried it myself, but i think, it should work... – anishsane Mar 10 '14 at 12:55
  • This doesn't work for me. I still get: `$ SUDO_ASKPASS=$HOME/askpass.sh; sudo -A "echo hello"` the following output: `sudo: no askpass program specified, try setting SUDO_ASKPASS` – white_gecko May 20 '15 at 12:41
  • @white_gecko: because you don't have the environment variable exported. Try: `export SUDO_ASKPASS=$HOME/askpass.sh; sudo -A "/bin/true"` – miklosq Jul 27 '16 at 21:22
  • My issue with this solution is that it implies to copy in cleartext the password to a file in the remote host (SudoPass.sh in your example). Isn't it a way to have SudoPass.sh prints the content of an environment variable and forward such variable via ssh without compromising the password on the command line? – user1448926 Jul 16 '19 at 10:46
2

Another way is to run sudo -S in order to "Write the prompt to the standard error and read the password from the standard input instead of using the terminal device" (according to man) together with cat:

cat | ssh user@domain.com 'sudo -S echo "foobar"'

Just input the password when being prompted to.

One advantage is that you can redirect the output of the remote command to a file without "[sudo] password for …" in it:

cat | ssh user@domain.com 'sudo -S tar c --one-file-system /' > backup.tar
simon04
  • 3,054
  • 29
  • 25
  • This got me closer.... (actually was prompted for the password), but typing did nothing. Instead, I got `[sudo] password for username: Sorry, try again.` automatically appearing 3 times then quitting. – Nathan J.B. Feb 19 '17 at 02:26
1

Defaults askpass=/usr/bin/ssh-askpass

ssh-askpass requires X server, so instead of providing a terminal (via -t, as suggested by nosid), you may forward X connection via -X:

ssh -X user@domain.com 'sudo echo "foobar"'

However, according to current documentation, askpass is set in sudo.conf as Path, not in sudoers.

Jan Hudec
  • 73,652
  • 13
  • 125
  • 172
-3

How about adding this in the sudoers file:

user    ALL=(ALL) NOPASSWD: ALL
Alexis Wilke
  • 19,179
  • 10
  • 84
  • 156
Akshat
  • 4,515
  • 4
  • 27
  • 28
  • 1
    I agree, but only recommended for servers that are in your control – Akshat Jul 12 '13 at 20:37
  • 5
    Removing sudo password requirements is bad. It's even worse if you specify no password for "ALL" executables. It's not something you should consider OK because the servers are in your control. There are safer alternatives which require no changes on the server at all. – Scott Prive Jul 30 '13 at 19:42
  • 2
    @Akshat I never assume that all my servers are in my control. I plan for the worst possible scenario :) – Josef Salyer Sep 09 '13 at 20:19
  • 1
    @JosefSalyer this is perfectly safe. For a command which required sudo, you have already stopped and considered your actions when you prefixed them with "sudo ". The prompt for sudo password adds no value (unless you're concerned about access control, but if you are you should be locking your terminal instead). If you want to automate your OS using a scripting language, you need to suppress these prompts. Automating your job with scripts is actually more secure than doing it by hand, since once you test the code you have removed the possibility of human error. – Scott Prive May 30 '14 at 13:54
  • This is the recommended best-practice for automated infrastructures that allow only public key auth. If someone screws up because they're fiddling with boxes manually, having an environment setup that can launch another instance automatically is probably the right way to go. (Core boxes should each have a dedicated private key w/ a passphrase divided in half amongst N people (2PK)) –  Jan 18 '15 at 19:28
  • 2
    This is a terrible practice from a security perspective. If you need to automate access to an operation which needs sudo access, you can have sudo allow specific access to commands without passwords with something like: `user ALL=(root) NOPASSWD:/path/to/bin with allowed args` This way you can allow the automation and still control who is allowed to do what on another user's behalf. – Joe Feb 17 '16 at 14:04