On 12/09/10 21:24, Rob Owens wrote:
On Sun, Sep 12, 2010 at 02:35:00PM -0400, Hal Vaughan wrote:On Sep 12, 2010, at 12:37 PM, Rob Owens wrote:...When using ssh keys to log in, you can specify (in ~/.ssh/authorized_keys) a command which will automatically run when that key is used to log in. And that key will be useless to do anything else. Simply using that key to conenct to the remote server will run that command. The authorized_keys file would look something like this: command="/path/to/my/script" ssh-rsa AAAAB3NzaC1yc2EAAA.... me@myhostI see. That would make perfect sense and I see I can use -i to specify which key to use, so for normal situations, I just use "ssh host," and when I want this done, I do "ssh -i .ssh/special_key host" instead. I thought I knew about authorized keys, but didn't know you could specify a command to be run in that file.You could use this to ssh into the remote server as root, or as a user with very specify sudo privileges that will allow your script to run. (The script would perform the file changes you need done, or simply rsync them from your local machine).But if I'm not running as root, from what I can see, no matter what I do with sudo, I still have to type in a password, don't I? using the authorized_keys file and specifying what can be done at login does a lot to help with security, but if I don't log in as root, no matter what I do, I'll still have to type in a password to use either "su" or "sudo," right? Or is there a way around it? I was going through man pages, but it seems both require a password to be typed in no matter what.In /etc/sudoers, you can specify "NOPASSWD", like this: someuser ALL=NOPASSWD: /path/to/some/command Then "someuser" can run the specified command as root without typing a password.When I tested this with some simple scripts, I find if I create a batch file that runs a few commands, like "chown root:root filename" that those commands, which would normally need the sudo command don't need it. Is this because of the (usually) 5 minute time limit sudo uses? Can I trust this on all systems, or is there anything that could prevent this behavior? In other words, if I include, in the script, commands that also need sudo, am I right that I can count on them executing without further need of verification?If you run "sudo somescript", then the script runs as root, so every command inside it will run as root. I think it is generally considered smarter, security-wise, to run "somescript" and then include "sudo" inside the script as necessary. For instance, your script might look like this: #!/bin/bash # # myscript.sh # sudo ls /root/* ls /home/* #doesn't need root privileges sudo touch /usr/local/somefile This script could be run as a regular user, but it would only run properly if the user had the appropriate sudo rights.
Note that sudo does not completely mimic root behaviour. Commands using >, and presumably other composite commands, will depend on the user's own permissions.
In an 'all-root' directory, with no existing file2: sudo cp file1 file2 works as expected sudo touch file2 works as expected sudo cat file1 works as expected sudo cat file1 > file2 fails due to lack of write permission su -c "cat file1 > file2", then <password>, works as expectedIt isn't just cat, I first noticed this some years ago with aggregate, which also uses >. I assume that when the shell reaches the >, which is effectively another command, the temporary sudo one-command permission has expired. The trick with the quotation marks doesn't work, sudo expects the entire quoted string to be the name of an executable.
-- Joe