[Duplicity-talk] adding stronger server-side protections for ssh backups.

[Rob Browning]

Apologies for the multiple posts, but after some more thinking and
looking around, below is what seemed like a possible way to allow for
safer ssh backups -- safer for the client because it would be less
likely that the client could clobber their own data, either
accidentally or maliciously, and safer for the server admin because it
would allow more precise limits on what the client is allowed to do.

The approach below may also be more convenient for the admin since (if
it works) it should allow multiple clients to back up to the server
using only one ssh account (but different keys), and still not be able
to access or affect each others' data.

As briefly suggested earlier, I'm wondering about creating a
duplicity-ssh-agent command that could be used via ssh's command="foo"
option for keys.  The idea is that it would behave like a very limited
scp, and allow the admin of the backup server to arrange various
client restrictions.  For example, the destination directory would be
set on the server side, not the client side, and the server admin
would be able to specify that the client isn't allowed to delete any
backups.  As it stands, with the current ssh/scp backend, I suspect a
malicous user who gains control of the client machine could fairly
easily destroy all of that machine's backups on the server.

To set things up for several client machines, say host-1, host-2, and
host-3, you would create client-specific ssh keys contaning
command="foo" options on the server -- perhaps something like this:

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

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

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

duplicity-ssh-agent would 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.

The client invocation might look something like this:

  duplicity /path/to/back/up \
            dssh://address@hidden/local/path/to/identity.pub

Note that in the above, the path to identity.pub would be the path on
the local machine, not the backup server.

In terms of implementation, from my initial brief examination of
duplicity's code, it seems like the dssh backend (and matching
duplicity-ssh-agent command) would probably just need to implement the
put, get, list, and delete operations.

If we arrange for duplicity-ssh-agent to look in SSH_ORIGINAL_COMMAND
to see what action the duplicity client is requesting, then we might
not even need to implement a "real" communication protocol.  i.e. the
duplicity client might be able to just make ssh calls for the various
actions somewhat like this:

  ssh -i ident address@hidden duplicity-ssh-agent list
  ssh -i ident address@hidden duplicity-ssh-agent put DESTINATION < datafile
  ssh -i ident address@hidden duplicity-ssh-agent get SOURCE
  ssh -i ident address@hidden duplicity-ssh-agent delete DESTINATION

In each case, on the server side, the invocation of
duplicity-ssh-agent via the command="..."  key option would 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 could 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 @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