restricting rsync over ssh on the server side.

Aaron Morris aaronmorris at mindspring.com
Sun Jan 5 18:09:00 EST 2003


I do not think you can use it with ssh, but if you use rsync in rsync 
mode (::) instead of just an interface to rsh (:), you can limit the 
directories where you can transfer files (using modules).  This involves 
setting up the rsync daemon on the server side.  The rsync daemon has 
the ability to limit connections, chroot itself, prevent the use of 
options (such as delete), use it's own authentication, setup 
includes/excludes on the server side, and use IP based ACLs (outside of 
tcpwrappers).  See:  `man rsyncd.conf`

I only mention this because I do not believe most people even realize 
there is this other mode to rsync.  I tried describing it to a co-worker 
who uses rsync regularly, but he kind of just stared at me blankly.

Rob Browning wrote:
> I was wondering if it's possible to restrict rsync in various ways on
> the server side when it is invoked via ssh.  Two restrictions I had in
> mind are disallowing deletes and/or restricting all actions to a
> particular subdirectory.  I was hoping to be able to do this without
> having to be root (for a chroot) or having to set up special sshd
> server instances/chroots.
> 
> If there's not already a way to do this, one possibility I had thought
> of is a ssh key command= wrapper, so that you could generate an ssh
> key like this:
> 
>   command="rsync-ssh-wrapper --root=/home/foo/bar --disable-delete",...
> 
> and then when invoked rsync-ssh-wrapper would then look at
> SSH_ORIGINAL_COMMAND to see the actual incoming request (presuming
> there were any relevant options there; are rsync --server invocations
> documented anywhere?), and combine that with the wrapper options to
> decide how to invoke rsync --server.  Of course this approach presumes
> that rsync --server would support suitable arguments.
> 
> Is there interest in such a facility?  It seems like something similar
> might be useful for sftp and scp as well, but I haven't managed to
> think of a way to implement a common solution.  Also, I could imagine
> that this solution for rsync might be somewhat difficult to implement
> (perhaps complicated by symlinks, etc.), but it's the best thing I've
> thought of so far.
> 
> Thanks
> 

-- 
Aaron W Morris
decep
PGP Key ID:  259978D1





More information about the rsync mailing list