restricting rsync over ssh on the server side.

Rob Browning rlb at
Mon Jan 6 00:33:00 EST 2003

jw schultz <jw at> writes:

> 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.

Perhaps so, but in the case of at least ssh (as compared to sftp or
scp), the problem seems to be much more general, probably requiring an
LD_PRELOAD or chroot solution since via ssh you can run any command.

On the other hand with rsync and a fixed command="foo" key that limits
the incoming user's command to an rsync-wrapper invocation, as long as
rsync has it has a clear idea of every place it uses a path, it seems
like supporting a --root=foo option when running as --server might be
fairly straightforward.  I would guess that the main tricky bits would
be handling (quashing) out-of-root symlinks and .. references safely.

For those interested, the reason I started thinking about this was
that I wanted to back up some machines via duplicity to their local
disk, and then rsync each one to a central server.  I wanted to make
sure that each machine could only rsync to its own area, had no other
access to the machine, and I didn't want to have to have one system
account per client on the backup host.

Although I think a rsync command designed to work with ssh's
command="foo" facility might be fairly useful, and I might revisit
this topic later, I think I'm going to first try to make time to fix
the similar issue in duplicity where the problem is somewhat simpler
because duplicity has a strict separation between its front and back
ends and only requires the backends to implement the list, put, get,
and delete commands.

See the duplicity-talk list for the recent details, but something
similar to the following might eventually be interesting for rsync

On the backup server you'd have:

  from="",command="/usr/bin/duplicity-ssh-backend --append-only --root /backup/dup/host-1"

  from="",command="/usr/bin/duplicity-ssh-backend --append-only --root /backup/dup/host-2"

  from="",command="/usr/bin/duplicity-ssh-backend --append-only --root /backup/dup/host-3"

duplicity-ssh-backend will be responsible for implementing duplicity's
server-side actions, making sure that each host is only be able to add
to its current backup set, and is only able to write beneath the given
root.  duplicity-ssh-backend will look in SSH_ORIGINAL_COMMAND to see
what action the duplicity client is requesting.  The client will run
requests that look something like this:

  ssh -i ident user at host duplicity-ssh-backend list
  ssh -i ident user at host duplicity-ssh-backend put DESTINATION < datafile
  ssh -i ident user at host duplicity-ssh-backend get SOURCE
  ssh -i ident user at host duplicity-ssh-backend delete DESTINATION

and in each case, on the server side, the invocation of
duplicity-ssh-backend via the command="..."  key option will examine
SSH_ORIGINAL_COMMAND and see the relevant "put DESTINATION" or "get
SOURCE" request, etc. and then decide based on that and its own
command line options (i.e. the --root and --append-only options above)
whether or not to allow and attempt the operation.

duplicity-ssh-agent will probably accept the "put" files on stdin,
return the "get" files on stdout, and return as much error information
as needed on standard error.


Rob Browning
rlb,, and
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4

More information about the rsync mailing list