Do you have a question? Post it now! No Registration Necessary. Now with pictures!
- Posted on
November 29, 2004, 9:03 pm
rate this thread
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"
case "$SSH_ORIGINAL_COMMAND" in
rsync\ --server\ -vvlogDtprz\ --delete\ .\ /d00*)
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
Is there a way to further limit this?
Is using rsync as a server a better option (can't use now because of
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.
Your rsync server can restrict what directories are made available to remote
clients (see rsyncd.conf, especially the path= and "use chroot" options).
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
IDFILE= private key for the someuser account you are using for
the ssh connection (~/.ssh/id_rsa)
- » My Linux server got hacked last night -- please help!
- — Previous thread in » Secure Shell Forum
- » ssh on command line: force using a group size (prime size) of 1024 (and no...
- — Newest thread in » Secure Shell Forum