Transport Performance / Protocol Overhead (remote shell vs daemon)

[Matt]

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 
command.

... 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.
>
> 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