set environment variable SSH_ASKPASS or askpass in sudoers, resp

Question

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

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


        

Answer 1

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

Answer 2

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.

Answer 3

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"

Answer 4

EDIT Dec 2013: Here's a shorter answer: Take a day or two to familiarize yourself with the Python library "Fabric". Fabric solves a ton of issues with regard to dispatching remote tasks to 1 or more servers.

You probably will still want to setup a username on the target system who can run passwordless commands (and you can use Fabric to do that also!).

Just beware that some aspects of Fabric are not perfectly Pythonic. Also, Fabric was designed first with sysadmins in mind, people who want to batch commands against servers. If you are trying to do something else (like automate some very specific servers or scenarios) you'll want to fully understand how "with settings" and/or the @roles decorator works. I haven't looked back...

(And yes, I got remote SSH commands working on "remote" systems. That is, server A asks server B to connect to server C, and the return of the command is seen on server A even though A doesn't talk directly to server C. Makes lab setup easier!).

Original response: There are MANY solutions to this problem. Horses for courses; some are better than others in different situations.

The question asked is, how to resolve the "no TTY" error. That seems to be the focus so I assume the talk about sudoers is just an attempt to workaround to avoid the TTY issue.

Option 1) Askhat's answer works great... most of the time. Actually, always specify "-tt" which works on more target systems.

Note you will still hit the problem if you are using an SSH library like Paramiko, which does not have an intuitive way of doing "-t".

Option 2) My answer - is to specify an ASKPASS which is STDIN. So this example satisfies both the sudo password requirement and the TTY: $ shell> ssh user@domain.com 'echo "password"|sudo -S echo "foobar"'

Option 3) Yes, you can disable sudo password checks on all or some users, but that's not cool on a production server.

Option 4) You can remote "requiretty" (or set "!requiretty" for all or some users in sudoers. Again, not cool on a production box.

It's best to avoid making server changes. Someday that server will be replaced, the settings going back to default, and your script will stop working.

Note that once you understand all of your options, it opens the doors to a lot more automation (for example a script on your laptop than can connect to a list of server hostnames, and perform sudo tasks ON those servers without you needing to copy said scripts onto those servers).

Answer 5

How about adding this in the sudoers file:

user    ALL=(ALL) NOPASSWD: ALL

Answer 6

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"'