This was originally posted to the lsh mailing list, and I am expanding
it to also include the rsync mailing list.
Niels: the primary author and current maintainer of rsync Andrew Tridgell
is away for a while so he probably won't be able to answer this very soon.
I was maintainer of rsync for a while and have some suggestions for you.
On Tue, Feb 22, 2000 at 05:45:24PM +0100, Niels M�ller wrote:
> Subject: Re: rsync protocol spec
> Hi,
>
> I'm hacking on lsh, a GPL:ed implementation of the secure shell
> protocols. Sooner or later, I want to add some file transfer features.
> Werner Koch suggested that instead of trying to get some spec for the
> undocumented protocol used by sftp, I should simply use rsync.
>
> I've never used rsync, but I'm trying to learn. I've read the man
> pages and the tech report, so I think I understand how it works. Now,
> one should be able to simply say
>
> RSYNC_RSH=lsh rsync ...
>
> to get going (not currently true, as lsh currently only works as an
> rlogin lookalike, not like a true rsh, but that should change).
>
> But I'd like to do some more.
>
> I'd like users to be able to export files using lsh's user
> authenticatin mechanisms and spki certificates (lsh's spki support is
> currently very limited, but that should also change). This way, a user
> can grant read or write access to some of his/her files to a certain
> key (or "spki principal"), for some period of time, and the owner of
> that key can also delegate some or all of that access further.
>
> My current ideas about that is to introduce an secsh "service" for
> rsync. If I have authorized some restricted rsync access to some of my
> files, then any user with the right certified keys can log in for
> rsync access, on my account, to list and transfer files.
>
> This would probably involve writing an rsync server more or less from
> scratch. Clients need less modifications. I think all an rsync client
> will need to do is to pass a user name, the service name "rsync" (as
> the default service to request is "ssh-connection"), and possibly some
> hints on which certificate to use. And that could be encapsulated in a
> wrapper around lsh.
>
> Next thing I need is a spec for the rsync protocol; i.e. a detailed
> descriptions of the formats used for the communication between rsync
> clients and servers. It might also be advantageous to do a more tight
> integration with the secsh protocol, but I'd really need the protocol
> spec to figure that out.
>
> Hmm, when thinking about it, one might also want to be able to use
> rsync when logged in using the usual, full access "ssh-connection"
> service. But that is probably a lot easier than restricted access.
>
> Best regards,
> /Niels
I'm sorry to tell you that a spec for the rsync protocol itself does not
exist because there really can't be one. The protocol used by the rsync
program is not designed to have multiple implementations, it is a highly
packed protocol that really only works because the same code is used on
both sides. The protocol also keeps getting revised (currently at revision
number 24) and the implementation is full of places checking the other
side's protocol version number to make sure the other side is talking the
same protocol.
There is another implementation of the rsync algorithm that was designed
to be for a more general purpose use and able to be standardized, but a
spec hasn't been written yet for that one either. It is a library that
was written for use in an http proxy called "rproxy". A paper about rproxy
is at ftp://samba.org/pub/tridge/rproxy/rproxy_paper.ps and the code for
librsync is at http://samba.org/cgi-bin/cvsweb/rproxy/librsync/, or see
samba.org/cvs.html for general info about the CVS archives there.
I do think that there is a need for more secure access on the rsync server
side for cases when users do not have logins on the servers. Currently
clients cannot be guaranteed that the server is not being spoofed, and the
only authentication of clients on the server is password based (although it
is a challenge-based password scheme; passwords are not sent in the clear
over the network) coupled with some tcpwrapper-style limits on hosts.
Clearly there would be some benefit from doing public key authentication in
both directions, so an integration with lsh seems like a good idea.
My suggestion is to not try to re-implement the rsync protocol in lsh, but
instead design some sort of interface between the lsh server and rsync, so
that authentication information can be passed from the lsh server to the
rsync server code, and then let rsync take over to do the data transfer.
I haven't thought through the details, but it seems like a more workable
approach.
- Dave Dykstra
