rsync server over SSH

[Martin Pool]

I haven't had a chance to test this recently, but Dave just reminded
me that it ought to merge soon and I agree.

I was thinking about this the other day in the context of the
Bitkeeper "bk url" manpage (if Colin will forgive me :-).

  http://www.bitkeeper.com/manpages/bk-url-1.html

They have basically the same problem of wanting to do access locally,
over a native protocol, and over ssh.  I'm not suggesting we adopt
their scheme.

It seems like people might want to set up accounts (called say
"backup") whose login shell is set to 'rsync --daemon'.  I'd like that
to work if it can.  It kind of overlaps with command-limited ssh keys,
but I think some admins would feel more comfortable with the former.

SSH2 also has a "subsystem" configuration option that seems to let it
provide tunnelled servers directly.  I wonder if we can integrate with
that?

I'm not sure if I said so before, but I'm not completely comfortable
with the -e option invoking the rsync-over-ssh behaviour.  I can see
how from one point of view this is quite elegant, but I'm concerned
that it overloads the behaviour of the option in a confusing way: it
would change it from merely modifying a mode selected by a
single-colon url, to choosing a new mode of behaviour.   (Imagine, for
example, somebody who has a shell alias that sets up rsync -e.)

A clearer way to put that is that at the moment we have six modes of
operation; this will make eight (counting upload and download
separately).  I think it's fair to insert rsync-over-ssh at that
level.  It is already a source of confusion and we have to be careful
not to make it worse.

All of the others are distinguished by whether the source and
destination contain colons, etc.  I think we ought to try to retain
that convention if possible.

Thanks again for the patch.  These issues should be pretty easy to
decide, and I think it will be a large improvement in utility.

-- 
Martin