Rsync via two ssh tunnels possible (standard method mentioned k times not possible?)

Matt McCutchen matt at
Wed Dec 17 16:50:26 GMT 2008

On Mon, 2008-12-15 at 10:54 +0100, Roman Fiedler wrote:
> Matt McCutchen wrote:
> > On Fri, 2008-12-12 at 12:56 +0100, Roman Fiedler wrote:
> >> The goal is to sync two directories using rsync without running the
> >> rsync daemon on one of the two hosts...
>  >
> > I suggest you just replace your "nc" command with an rsync daemon
> > listening on port 6666 on the SRC machine.  This isn't any less secure
> > than what you're trying now.
> In the end I hope to run the two rsyncs just using the stdin/out of the 
> two ssh connections and the relay connection is done on the local host, 
> the nc thing is just for testing because it's easier to strace.
> > If you really don't want an rsync daemon anywhere in the picture (though
> > I'm not clear on why),
> I hoped that I do not have to create a .conf file for the daemon (or 
> fiddle around with the cmd parameters) and that I do not need to care 
> about the auth settings for the daemon. Apart from that my rsync via 
> cmdline would run only once and terminate immediately after sync and 
> closing the ssh connection would stop the server thread if not 
> terminated before.

My point stands that the daemon is an improvement compared to the "nc"
setup you originally described because it passes the server arguments
for you.  You would need to write a configuration file (see the examples
in rsyncd.conf(5)), but you needn't set up authentication.

I understand that you're looking for a solution better than either of
those.  A "single-use" daemon, which retains the advantage of passing
the server arguments for you but handles a single client connection on
stdin/stdout instead of listening on a port, may figure in that

Starting from the local machine, you could invoke both the single-use
daemon on SRC and the client on DST and tie them together with a few
pipes.  The client on DST needs to be made to use the existing
stdin/stdout instead of making its own connection.  You can do that with
shell magic (might be slow) or using a proposed rsync patch (which
probably needs a slight modification because ssh appears to use separate
pipes for stdin and stdout instead of a single socket).  For information
about both approaches, see:

For the plumbing on the local machine, you could just make two named
pipes and connect each ssh's stdin and stdout to the pipes, with the two
ssh-es in opposite directions.

> > you could use a single-colon source argument with
> > "-e 'nc localhost 4444 #'" to have the client connect to the
> forwarded
> > port and expect a bare server.
> I tried that, but rsync tried to execute
> [pid  8953] execve("/bin/nc", ["nc", "localhost", "1235", "#", 
> "localhost", "rsync", "--server", "--sender", ".", "src"], [/* 23
> vars 
> */]) = 0
> The additional args caused nc to fail.

Oh.  I remembered using something like that, but apparently it was with
--rsync-path, which goes through the shell (and the # comments out the
remaining arguments).  Rsync parses -e itself.


More information about the rsync mailing list