Locking down ssh commands, while using rsync.

I have a questions regarding the locking down of commands while using
rsync.

I have two servers, and need to copy a complete filesystem from server
"A" to server "B". Because of permission issues on the filesystem,
the only way I can figure this out is by creating a null password key
for root, and copying it over to server "B", and performing an rsync
as root. I then tried to limit root's access by configuring the
authorized_keys file with the "from=" and the "command=" options. So
far so good, the only thing is I can't seem to limit what is being
copied over to server "B"

I.E. authorized_keys

from="host_a.mysite.com",command="/usr/local/bin/validate-rsync"
ssh-rsa keyinfo


cat /usr/local/bin/validate-rsync

#!/bin/sh

case "$SSH_ORIGINAL_COMMAND" in
*\&*)
echo "Rejected"
;;
*\;*)
echo "Rejected"
;;
rsync\ --server\ -vvlogDtprz\ --delete\ .\ /d00*)
$SSH_ORIGINAL_COMMAND
;;
*)
echo "Rejected"
;;
esac



From "A" server I run:

rsync -avvz -e ssh --delete /d00/primary host_b.mysite.com:/d00




This works fine, but the command ("$SSH_ORIGINAL_COMMAND") that is
executed
on the other side is: "rsync --server -vvlogDtprz --delete . /d00"
How can I limit what data is sent. What I am trying to avoid is an
admin rsyncing the wrong filesystem to the remote host. It seems in
this configuration the root user can copy any filesystem to
host_b:/d00, I want to ensure that the only filesystem that may be
copied is /d00/primary. I will be scripting this rsync, and will
execute via cron, but I want to ensure that the backup filesystem
isn't stepped.

Is there a way to further limit this?

Is using rsync as a server a better option (can't use now because of
firewall restrictions)?

Should I be looking at initiating the rync as root, but push the data
acrossed as another user (right now we are performing a ufsdump, then
scping the data across, and the restoring when it is needed)?

"Snoopy_" <snoopy_@excite.com> wrote in message
news:e71fbf62.0411291303.4a081f2f@posting.google.c om...
> I have a questions regarding the locking down of commands while using
> rsync.
>
> I have two servers, and need to copy a complete filesystem from server
> "A" to server "B". Because of permission issues on the filesystem,
> the only way I can figure this out is by creating a null password key
> for root, and copying it over to server "B", and performing an rsync
> as root. I then tried to limit root's access by configuring the
> authorized_keys file with the "from=" and the "command=" options. So
> far so good, the only thing is I can't seem to limit what is being
> copied over to server "B"
>
> I.E. authorized_keys
>
> from="host_a.mysite.com",command="/usr/local/bin/validate-rsync"
> ssh-rsa keyinfo
>
>
> cat /usr/local/bin/validate-rsync
>
> #!/bin/sh
>
> case "$SSH_ORIGINAL_COMMAND" in
> *\&*)
> echo "Rejected"
> ;;
> *\;*)
> echo "Rejected"
> ;;
> rsync\ --server\ -vvlogDtprz\ --delete\ .\ /d00*)
> $SSH_ORIGINAL_COMMAND
> ;;
> *)
> echo "Rejected"
> ;;
> esac
>
>
>
> From "A" server I run:
>
> rsync -avvz -e ssh --delete /d00/primary host_b.mysite.com:/d00
>
>
>
>
> This works fine, but the command ("$SSH_ORIGINAL_COMMAND") that is
> executed
> on the other side is: "rsync --server -vvlogDtprz --delete . /d00"
> How can I limit what data is sent. What I am trying to avoid is an
> admin rsyncing the wrong filesystem to the remote host. It seems in
> this configuration the root user can copy any filesystem to
> host_b:/d00, I want to ensure that the only filesystem that may be
> copied is /d00/primary. I will be scripting this rsync, and will
> execute via cron, but I want to ensure that the backup filesystem
> isn't stepped.
>
> Is there a way to further limit this?
>
> Is using rsync as a server a better option (can't use now because of
> firewall restrictions)?

Probably...
Your rsync server can restrict what directories are made available to remote
clients (see rsyncd.conf, especially the path= and "use chroot" options).


>
> Should I be looking at initiating the rync as root, but push the data
> acrossed as another user (right now we are performing a ufsdump, then
> scping the data across, and the restoring when it is needed)?


Consider using an ssh tunnel through your firewall from your client to the
rsyncd service. Intiate rsync by a non-root user on the remote end if you
wish, but the rsyncd server must run as root to avoid permission problems.

Alternatively, as you suggest, pipe your ufsdump output through an ssh
connection to the remote host and deposit the ufsdump file as a non-root
account. If you setup the public keys right, you can avoid a password
prompt.

for example: ufsdump 0f - $FS | ssh -i {IDFILE} someuser@hostB "dd
of=/home/nonroot/mydumpfile "

IDFILE= private key for the someuser account you are using for
the ssh connection (~/.ssh/id_rsa)