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
