restricting rsync over ssh on the server side.

[Rob Browning]

jw schultz <jw at pegasys.ws> 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
--server...

On the backup server you'd have:

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

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

  from="host-3.foo.bar",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.

FWIW

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