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 -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
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
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@pegasys.ws Remember Cernan and Schmitt