In the message dated: Sat, 18 Feb 2006 23:09:31 EST,
The pithy ruminations from "Brian Wilson" on
<[BackupPC-users] escaping command line options> were:
[SNIP!]
=>
=> Anyways, I'm attempting to do a remote rsync of a machine over ssh
=> with sudo. The backup is successful as long as I don't use the
=> command="/home/user/bin/rsync-wrapper.sh" directive in my ssh
=> authorized_keys file. I am guessing it has something to do with the
=> escaping of things as they get passed to the script.
=>
=> The script doesn't modify the command passed to it, it just checks to
=> make sure I'm running an allowed command:
=>
=> #!/bin/sh
=>
=> case "$SSH_ORIGINAL_COMMAND" in
=> *\&*)
=> echo "Rejected"
=> ;;
=> *\(*)
=> echo "Rejected"
=> ;;
=> *\{*)
=> echo "Rejected"
=> ;;
=> *\;*)
=> echo "Rejected"
=> ;;
=> *\<*)
=> echo "Rejected"
=> ;;
=> *\`*)
=> echo "Rejected"
=> ;;
This looks good at first, but it's almost certain to be incomplete...it's
extremely difficult to accurately specify all commands and meta-character
patterns that should be _excluded_. For example; what about:
ssh server nice -n 19 sudo \
/usr/bin/rsync --server /path/that/does/not/exist || \
perl -p -i -e 's/^root:[^:]+//' /etc/shadow'
(untested, but this should be allowed by your wrapper script...when the rsync
command fails, because "/path/that/does/not/exist", then the perl command gets
run, as root. The perl command will remove the root password from the
/etc/shadow file).
=> nice\ -n\ 19\ sudo\ /usr/bin/rsync\ --server*)
=> $SSH_ORIGINAL_COMMAND
=> ;;
=> *)
=> echo "Rejected"
=> ;;
=> esac
=>
=> When going through the rsync-wrapper, the backup happens, but it backs
If I understand it, the only allowed command is:
nice -n 19 sudo /usr/bin/rsync --server
correct?
[SNIP!]
=>
=> If someone has a better suggestion for a wrapper script so I can only
=> allow this user to run the backup command over ssh, then please let me
=> know.
Well, ssh has a native mechanism for restricting the commands that can be run.
Establish an ssh public key pair to be used exclusively for backups. On the
server, use the "command" option in the authorized_keys file, in the subset
for the specified key, as in:
----------excerpt from /root/.ssh/authorized_keys -----------------------
command="nice -n 19 sudo /usr/bin/rsync --server" 1024 35 1600....1821
rsync-proxy
--------------------------------------------------------------------
Once this is set up:
[EMAIL PROTECTED] % ssh [EMAIL PROTECTED]
supply the "rsync-proxy" ssh key, either via the
command line, or prior to establishing the connection
by using "ssh-agent" and "ssh-add".
Regardless of what arguments (if any) the untrusteduser gives to the ssh
command when they connect to backupserver, only the command specified in the
authorized_keys file will be run.
See:
man sshd
http://www.snailbook.com/faq/restricted-scp.auto.html
http://www.dmz.ie/~cian/sshroles.html
http://www.hackinglinuxexposed.com/articles/20040923.html
Mark
=>
=> Thanks,
=> Brian
----
Mark Bergman
[EMAIL PROTECTED]
Seeking a Unix/Linux sysadmin position local to Philadelphia or telecommuting
http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=bergman%40merctech.com
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/
