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

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).