Is there a way to transfer my sudo password via ssh so that I can copy files remotely and pass them locally, so:
cat sudo-passwd-file|ssh -t user@10.7.0.180 'sudo find / -depth|cpio -oacv|gzip' > /path/to/dir/file.cpio.gz
I am in the process of a creating a script. Everytime I try and just do this I get:
cat passwd-file|ssh -t user@10.7.0.180 'sudo find / -depth'
Pseudo-terminal will not be allocated because stdin is not a terminal.
sudo: no tty present and no askpass program specified
??
Couldnt I just:
connect to 10.7.0.180 and add a newline or edit existing to look like
user ALL=(ALL) NOPASSWD: /usr/bin/find
find can execute arbitrary programs. Allowing anyone to run it as root is a gaping security hole.
it doenst work:
cat bobo | ssh -t -t user@10.7.0.180 "sudo find / -depth"
password
[sudo] password for user:
??
That is a good point.
If it isn't waiting for the prompt to type in the password, you may have to use a third-party utility like expect.
You could also configure sudo to allow it in a more careful manner -- only allow the 'find' command for a certain user, and with those exact arguments, which would prevent someone executing arbitrary commands as root with it.
Many thanks for the reply. I made the correction and made it specific to a user:
user ALL=NOPASSWD: /usr/bin/find, /bin/cpio, /bin/gzip
and noticed that now when I perform a:
ssh -o "PasswordAuthentication no" -o "HostbasedAuthentication yes" -l user 10.7.0.180 "find / -depth|cpio -oacv|gzip" > /path/to/dir/file.cpio.gz
I am getting from cpio:
cpio: /etc/ConsoleKit/seats.d/00-primary.seat: Cannot utime: Operation not permitted
/etc/ConsoleKit/seats.d/00-primary.seat
/etc/ConsoleKit/seats.d
/etc/ConsoleKit
cpio: /etc/blkid.conf: Cannot utime: Operation not permitted
/etc/blkid.conf
cpio: /etc/cron.d/anacron: Cannot utime: Operation not permitted
/etc/cron.d/anacron
cpio: /etc/cron.d/.placeholder: Cannot utime: Operation not permitted
/etc/cron.d/.placeholder
/etc/cron.d
cpio: /etc/idmapd.conf: Cannot utime: Operation not permitted
This doesnt happen on my other server. Any ideas ??
You haven't actually run any of those commands with sudo, therefore, none of them actually get run with sudo...
Here is my testing scenario.
/etc/sudoers
user ALL=NOPASSWD: /usr/bin/find, /bin/cpio, /bin/gzip
I know hostbased authentication is working:
ssh -t -t -o "PasswordAuthentication no" -o "HostbasedAuthentication yes" -l user 10.7.0.180
Linux 2.6.32-30-generic #59-Ubuntu SMP Tue Mar 1 21:30:21 UTC 2011 i686 GNU/Linux
Ubuntu 10.04.2 LTS
Welcome to Ubuntu!
* Documentation: https://help.ubuntu.com/
Last login: Fri Feb 17 10:30:18 2012 from 10.7.0.112
user@mymachine:~$
When testing the command with sudo, it is still prompting me for a password.
ssh -t -o "PasswordAuthentication no" -o "HostbasedAuthentication yes" -l user 10.7.0.180 "sudo find / -depth"
[sudo] password for user:
??
---------- Post updated at 11:35 AM ---------- Previous update was at 10:41 AM ----------
I even changed
/etc/sudoers
user ALL = NOPASSWD: ALL
and it still prompts for a password:
user@mymachine:~$ ssh -t -o "PasswordAuthentication no" -o "HostbasedAuthentication yes" -l user 10.7.0.180 "sudo find / -depth"
[sudo] password for user:
but when just using:
ssh -t -t -o "PasswordAuthentication no" -o "HostbasedAuthentication yes" -l user 10.7.0.180
Linux 2.6.32-30-generic #59-Ubuntu SMP Tue Mar 1 21:30:21 UTC 2011 i686 GNU/Linux
Ubuntu 10.04.2 LTS
Welcome to Ubuntu!
* Documentation: https://help.ubuntu.com/
Last login: Fri Feb 17 10:30:18 2012 from 10.7.0.112
user@mymachine:~$
its fine. ?????????????
How did you edit the sudoers file?
I logged in as root, chmod /etc/sudoers from 440 to 600. Added my entry and then changed it back to 440 and rebooted the machine. This is an Ubuntu 10.04 build.
The proper way to edit sudoers is with the 'visudo' command. Hand-editing it is not supposed to work.
I switched over and used visudo and it didnt make a difference.
The code in sudo checks to see that its STDIN is a terminal, specifically trying to defeat input redirection from a file. The idea being that you should never put a clear text password in a file anywhere. Sudo wants to force you to manually enter the password on a keyboard in real time in order to run.
A utility like expect can be used to defeat this, but then you're just putting the clear text password into the expect file, which certainly isn't at all secure.
One secure solution would be to set up a root cron job on the target system to do the find periodically and make the output world readable in /tmp. Then you can set up a private/public key pair and just scp or cat the file whenever you like. Not quite real time, but reasonably timely, depending on the interval of the cron job.
Another method I've seen used is to set up key pairs and use scp to drop a trigger file of a particular name (which can be zero length) into predetermined location on the target system. This can be done as a normal user. There's a root cron job on the target system that runs every minute and looks for the trigger file. If found, root takes some predetermined action and then removes the trigger file. I recall an implementation of this where an admin had root doing all sorts of tasks on remote systems, depending on the name or the contents of the trigger file. The actions that root can take are spcifically coded into the cron script, which is only readable by root, so there's no danger of executing arbitrary code. You could trigger the action with the presence of the file and pass arguments as contents of the file.
Sort of the poor man's AutoSys or UC4...
Whatever you decide to do, please keep security in mind.
Cheers!
I would make it like this :
Make a script.sh on machine(server) you are trying to run find / gzip.
if ! [ -f /tmp/lockme ]; then
touch /tmp/lockme
##sudo code goes here
rm -f /tmp/lockme
else
echo "already running, try again later"
fi
On client side i would exchange ssh-keys as user to sudo-user on server (passwordless).
authorized keys on server will have to be modified in manner like :
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/path/to/script.sh" ssh-rsa # rest # sudo-user@server
So whenever a user runs
ssh sudo-user@server
It will run script.sh
It's not ultra secure, but much safer then using sudo with expect over ssh.
It definately has to due with what I have inside of the sudoers file:
ssh -t -t -o "PasswordAuthentication no" -o "HostbasedAuthentication yes" -l user 10.7.0.180
Linux 2.6.32-30-generic #59-Ubuntu SMP Tue Mar 1 21:30:21 UTC 2011 i686 GNU/Linux
Ubuntu 10.04.2 LTS
Welcome to Ubuntu!
* Documentation: https://help.ubuntu.com/
user@10.7.0.180:~$ sudo find / -depth
[sudo] password for user:
As you can see, after logging in, I am still getting prompted for a password.
---------- Post updated at 01:05 PM ---------- Previous update was at 11:36 AM ----------
It was in fact /etc/sudoers and the placement of my entry, so from:
root ALL=(ALL) ALL
user ALL = NOPASSWD: /usr/bin/find, /bin/cpio, /bin/gzip
to
# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL
user ALL = NOPASSWD: /usr/bin/find, /bin/cpio, /bin/gzip, /bin/cat
worked like a charm.
11.10 - Why is sudoers NOPASSWD option not working? - Ask Ubuntu - Stack Exchange