Locking down ssh commands, while using rsync.

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
I have a questions regarding the locking down of commands while using

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  

ssh-rsa keyinfo

cat /usr/local/bin/validate-rsync


                echo "Rejected"
                echo "Rejected"
        rsync\ --server\ -vvlogDtprz\ --delete\ .\ /d00*)
                echo "Rejected"

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
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)?

Re: Locking down ssh commands, while using rsync.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

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

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

Site Timeline