Transport Performance / Protocol Overhead (remote shell vs daemon)

Matt McCutchen hashproduct+rsync at gmail.com
Mon May 28 02:42:56 GMT 2007


On 5/24/07, a user <wsherman at apexelectriclv.com> wrote:
> > If you mean a background daemon contacted over a
> > port forwarded by ssh, tell me because many of the
> > answers would be different.
>
> Yes, that.

OK...

> 1) Rsync to remote host via an ssh tunnel to an Rsync daemon
> vs.
> 2) Rsync to remote host via ssh remote shell

> - Is there a performance difference in throughput or latency?
> - Which one has higher protocol overhead?
> - Any memory usage differences?
.
I can't think of anything that would cause a significant difference
between the two methods in any of these areas, but try both and see.

> - Does it matter if we are sending files or receiving them?

It shouldn't matter.

> - Security implications?  Is one more secure than another?

In #2, the client logs into a remote account via ssh, and rsync uses
the power of that account.  In #1, the client logs into the *daemon*,
which then offers it carefully controlled access to a few directories
with the power of the remote user that started the daemon; how the
daemon is reached is less important.  From a security perspective, #2
is no different from plain ssh, while in #1, the daemon offers the
client an rsync "capability".  #1 is more complicated because you have
to set up a separate daemon-level username and password.

If the client already has (or might as well have) full ssh access to a
remote account that can manipulate the files in question according to
file permissions, use #2: it's simpler and easier.  If you are
reluctant to grant the client full ssh access to such an account, you
can use #1 instead.

- - -

If you're considering #1: Port forwarding has two disadvantages: a
port forward must be set up beforehand in a separate command, and
other users on the local machine can piggyback on it.  I just found
two alternative ways to get rsync to connect to a background daemon
through ssh without using port forwarding, avoiding these
disadvantages.  Here they are:

#1a. rsync -e 'ssh -l sshuser' --rsync-path='nc localhost 873 #'
daemonuser at host::module/ ...

("nc localhost 873 # --daemon --server ." is invoked over ssh, the
right part being commented out.)

#1b. RSYNC_CONNECT_PROG='ssh -l sshuser host nc localhost 873' rsync
daemonuser at foo::module/ ...

Wayne: you might like to mention one or both of these on
http://rsync.samba.org/firewall.html .

Matt


More information about the rsync mailing list