Transport Performance / Protocol Overhead (remote shell
langelino at gmx.net
Wed May 30 00:27:52 GMT 2007
Matt McC. and Wayne S.,
note that with #1 you are doing TCP over TCP which is usually regarded
as sub-optimal, see http://sites.inka.de/~W1011/devel/tcp-tcp.html.
Wayne S., if you are always running the same rsync, you may also like
to consider using a ssh with public-key authentication and forced
... another Matt (Matt M.)
Matt McCutchen wrote:
> 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.
>> 1) Rsync to remote host via an ssh tunnel to an Rsync daemon
>> 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 .
More information about the rsync