2000-09-18-09:15:49 Sanjeev Jha:
> just wondering if any of you have experience with rsync through
> "stunnel" using openssl.
No experience, but I think I can put my finger on the nubbin of the
problem.
It's easy to arrange a stunnel daemon to offer a network service
through SSL. You will probably want to make it authenticate via
client certificate, since there won't be any other authentication
protocol working for you with direct rsync-over-SSL.
The next piece of the problem would be rigging rsync to _work_ over
SSL. One easy way to do it would be to have the client
(originating) end use stunnel -c (client side stunnel) as it's rsh
command, with rsync's "-e" option or the RSYNC_RSH environment
variable. The only problem with this approach is that, unlike rsh
or ssh, SSL is _not_ a remote-command-execution protocol, and has
no provision for passing across a command to execute. So stunnel
client will have to ignore the arguments that rsync passes it (a
wrapper script can take care of this), and the stunnel server will
have to be invoking rsync with the options hard-coded. This will
work for a single specific rsync invocation, but if you need
varying rsync invocations then it won't.
Server side:
stunnel -d `hostname`:XXX -l rsync -- rsync --server . . .
where ". . ." are the hard-coded options, and XXX is the port you
choose for this special new protocol.
The client complement to that would be something like
rsync -e stunnel-wrapper . . .
where stunnel-wrapper ignores the args and invokes stunnel to make
the connection:
#!/bin/sh
exec stunnel -c -r remotehost:XXX
The full-function way to do the deed would be to use rsync's daemon
mode. The server side will be easy, you can run a persistent rsync
daemon bound only to localhost then have stunnel proxy for that:
rsync --daemon --address=127.0.0.1
stunnel -d `hostname`:XXX -r 127.0.0.1:873 ...
The -T option to stunnel, if it works on your system, would let
rsyncd see the real originating host. XXX is a port number; you're
inventing a new protocol here (rsync-over-SSL), so you get to pick
your own port number if you want to. Or you can use 873.
Or you can have a persistent stunnel fire up rsync daemons
inetd-style as needed:
stunnel -d `hostname`:XXX -l rsync -- rsync --daemon
or even run stunnel from inetd, and have _it_ run rsync inetd-style;
that would be an inetd.conf line something like
rsyncs stream tcp nowait root stunnel -l rsync -- rsync --daemon
where you have an /etc/services line that maps the name rsyncs onto
your chosen port number:
rsyncs XXX/tcp
The client side is a little trickier; for rsync-server protocol I
don't see any direct way to specify a transport command, so you will
need to redirect the rsync client to some local port, and have a
stunnel there waiting to carry you across to the remote server. E.g.
on the client end run perhaps
stunnel -d 127.0.0.1:873 -r remotehost:873 ...
then have rsync refer to localhost::path for the remote end. You can
bind the stunnel to another port, and use the rsync://host:port/
notation to specify an alternate port, but the man page suggests
that for some reason that's not symmetrically implemented, and only
works for downloading, not for uploading. I'm not sure why that
would be, but then I've never used rsync daemon mode.
Allow me to recommend that instead of tunneling over SSL with
stunnel, you instead tunnel over ssh; it enjoys comparable
cryptographic strength, simpler use (ssh-keygen is _way_ easier
than generating certificates with openssl), and better
supported by rsync.
I just noticed something that sounds like an alternative of possible
interest, if you're seriously committed to SSL for some reason;
there seems to be a thing called slush, which aims to provide ssh
functionality over SSL, and is derived from stunnel. Unfortunately,
I can't seem to find any mirrors off its home site
<URL:http://violet.ibs.com.au/slush/>, and that machine is also the
home site for the OpenSSL RPMs, and I haven't been able to connect
to that site since the 0.9.1-beta1 OpenSSL release. But slush would,
if it works like it sounds, probably be just about a drop-in
replacement for ssh in "rsync -e" configuration, which means it'd be
a considerably easier way to set up rsync-over-SSL.
-Bennett
PGP signature
