restricting rsync over ssh on the server side.

jw schultz jw at
Sun Jan 5 20:15:00 EST 2003

On Sun, Jan 05, 2003 at 11:30:41AM -0600, 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.

This is really an issue for the wrapper not the utility.
Unless you use the key-based wrapper tightening rsync isn't
going to gain you much when the user can execute rm or scp.

A general purpose wrapper could be done but you would have
to have ways to tell it to require these options, disallow
these options, which of those options require args, and what
arguments must match what patterns.  A full implementation
would probably need a config file per invocation.

I'd say this topic is really better suited to the openssh
list.  The outcome, if useful, i think would be worth a
link on the rsync resources page.

	J.W. Schultz            Pegasystems Technologies
	email address:		jw at

		Remember Cernan and Schmitt

More information about the rsync mailing list