ssh foo.com sudo command - Prompts for sudo password as visible text. Help?

I am writing a BASH script to update a webserver and then restart Apache. It looks basically like this:

#!/bin/bash
rsync /path/on/local/machine/ foo.com:path/on/remote/machine/
ssh foo.com sudo /etc/init.d/apache2 reload

rsync and ssh don't prompt for a password, because I have DSA encryption keys. However, if rsync or ssh did prompt for a password, it would be invisible as I typed it in.

Sadly, sudo does prompt for a password. Not only that, the password gets displayed on the screen of my local machine as I type it.

Edited to add this paragraph:
Here is an example of what happens:

local-box$ ./myScript.sh
[sudo] password for fluoborate:

It wants the password for "sudo /etc/init.d/apache2 reload", and it wants the password for the user fluoborate on remote-box. When I type in the password, it appears, it is visible on my screen (the screen of local-box).

Possible solutions:

  1. Ideally, I would like to be able to do something like this:
sudo --password=thisIsThePassword /etc/init.d/apache2 reload

Before you balk at how insecure that is: I would prompt for the password earlier in the script, rather than hard-coding it, so reading the source code will not include the password. Also, nobody else can login to the remote machine, so they cannot see the command line arguments or look at my BASH history.

  1. Modify my sudoers file. I don't want to do this, and I haven't been able to figure out how. I am on Ubuntu (10.10 server, iirc). I can make it never prompt for a sudo password, but I cannot make it always prompt except for the one command "sudo /etc/init.d/apache2 reload". If you can provide very explicit instructions to get that working, then please do, I will be forever grateful.

  2. Use expect. I simply don't want to do this, it is ugly.

Thank you for the help.

What I don't understand is when does sudo intervene ?
On local box in order to be root to rsync?

More clarification:

This script does not prompt for a password:

rsync /path/on/local/box/ foo.com:path/on/remote/box/
ssh foo.com ls

...that script will happily perform the rsync and then print the listing of a directory on remote-box. SSH and rsync do not require a password because I have DSA keys installed.

This script does prompt for a password:

ssh foo.com sudo ls

...when I run that script, it pauses and prints:

[sudo] password for fluoborate:

...and when I type it in, my typing is visible.

So I understand here
you connect as fluoborate at foo.com then want to change effective ID (sudo) to root for executing ls
That means you have to look at the sudoers file on foo.com and add a newline or edit existing to look like

fluoborate ALL=(ALL)               NOPASSWD: /usr/bin/ls

I found some literature:
Using rdist rsync with sudo for remote updating - BigAdmin - wikis.sun.com

Hope that will help...

All the best

I am trying to do that sudoers magic, but it doesn't work. It either prompts for a password for everything or nothing, but I want it to only not prompt for:

sudo /etc/init.d/apache2 reload

Exactly what line should I add to sudoers? Does it matter how many spaces I put in the middle of the line? Is there a problem because "/etc/init.d/apache2 reload" contains a space? Maybe I need to type "/etc/init.d/apache2\ reload" in sudoers?

I have tried a bunch of things, I can't make it work. I invite you to try things on your own sudoers file. However, I can't think of another command that requires superuser permissions and has a space in it.

Thanks.

Did you try

"/etc/init.d/apache2 reload"

? (should work...)

I just tested on my HP-UX, doesn't like double quotes...
But this worked:

ant:/users/jju $ sudo /sbin/init.d/apache stop
ant:/users/jju $ ps -ef|grep apa
     www  1823  1808  0  Sep  6  ?         0:00 /opt/hpws/apache/bin/httpd -d /opt/hpws/apache -k start
     www  1825  1808  0  Sep  6  ?         0:00 /opt/hpws/apache/bin/httpd -d /opt/hpws/apache -k start
    root  1808     1  0  Sep  6  ?         4:08 /opt/hpws/apache/bin/httpd -d /opt/hpws/apache -k start
     www  1810  1808  0  Sep  6  ?         0:00 /opt/hpws/apache/bin/httpd -d /opt/hpws/apache -k start
     jju  9306  9002  1 19:12:12 pts/14    0:00 grep apa
ant://users/jju $ sudo /sbin/init.d/apache start
Apache Started..
ant:/users/jju $ r ps
ps -ef|grep apa
     www  1823  1808  0  Sep  6  ?         0:00 /opt/hpws/apache/bin/httpd -d /opt/hpws/apache -k start
     www  1825  1808  0  Sep  6  ?         0:00 /opt/hpws/apache/bin/httpd -d /opt/hpws/apache -k start
     www  9316  9312  0 19:12:29 ?         0:00 /opt/apache/bin/httpd
    root  1808     1  0  Sep  6  ?         4:08 /opt/hpws/apache/bin/httpd -d /opt/hpws/apache -k start
     www  1810  1808  0  Sep  6  ?         0:00 /opt/hpws/apache/bin/httpd -d /opt/hpws/apache -k start
     www  9315  9312  0 19:12:29 ?         0:00 /opt/apache/bin/httpd
     www  9317  9312  0 19:12:29 ?         0:00 /opt/apache/bin/httpd
     www  9314  9312  0 19:12:29 ?         0:00 /opt/apache/bin/httpd
     www  9313  9312  0 19:12:29 ?         0:00 /opt/apache/bin/httpd
    root  9312     1  0 19:12:28 ?         0:00 /opt/apache/bin/httpd
     jju  9319  9002  1 19:12:33 pts/14    0:00 grep apa
ant:/users/jju $ id
uid=6206(jju) gid=150(sei) groups=2(bin),60(oper)

And in sudoers:

jju ant = NOPASSWD : /sbin/init.d/apache st*

only jju has in .kshrc:

sudo=/usr/local/bin/sudo -u root 
1 Like

ssh -t should allocate a terminal, allowing it to control terminal characteristics, preventing things from seeing your typing.

That sudo is willing to ask for a password at all without a terminal is surprising.

vbe: I think your final suggestion worked. Prior to you posting the final suggestion, I independently discovered that sudoers doesn't like double-quotes. It was actually kind of annoying, because the syntax error was non-descriptive. It didn't even report the correct line for the error, it said "near line 27" when the double-quotes were on line 29. Line 27 was blank. I mustn't grumble, though.

Corona688: I was also surprised that sudo would ask for a password and echo the input to the screen. It is a terrible and naughty thing to do.