rsync - Oct 2006 - DO NOT REPLY [Bug 4163] New: Checksum Error using "ssh key authentication"

https://bugzilla.samba.org/show_bug.cgi?id=4163

           Summary: Checksum Error using "ssh key authentication"
           Product: rsync
           Version: 2.6.6
          Platform: x86
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: core
        AssignedTo: wayned@samba.org
        ReportedBy: cwlin@kingb.com.tw
         QAContact: rsync-qa@samba.org


Rsync works quite well with password entering in ssh.

However, if the option -e "ssh -i $HOME/.ssh/rsync_rsa" is used,
the error message "Invalid checksum length xxxxx [sender]" will be
reported.

The other options used here is "-avvv --delete".
The last few lines of the messages are as follows:

send_file_list done
send_files starting
deleting i386/.listing_old
send_files(1, /cygdrive/d/suse/i386)
i386/
send_files(2, /cygdrive/d/suse/i386/.listing)
_exit_cleanup(code=2, file=/home/lapo/packaging/tmp/rsync-2.6.6/io.c,
line=937):
 about to call exit(2)


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=4163


wayned@samba.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED




------- Comment #1 from wayned@samba.org  2006-10-11 22:42 MST -------
rsync doesn't care what ssh options you use as long as (1) ssh doesn't
output
anything to stdout, and (2) ssh passes through all character sequences, without
exception (i.e. you must not trigger the interactive escapes).

See the savetransfer.c program in the support directory of the distribtuion for
a program that you can use to check the data being sent over the wire.  The
comments at the top of the file describe how to use it.  You can then test to
see if corruption is happening between one side and the other (if the
client/server files don't match).  If they do match, you can contact me to
help
you interpret the contents of one of the files to see what is wrong with the
data stream.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=4163





------- Comment #2 from cwlin@kingb.com.tw  2006-10-12 02:16 MST -------
I did try the savetransfer program as you suggest.
The first two commands (for the "push" rsync) are being used.
The stream of data are logged in the client side, but none appears in the
server side.
Looks like the "remote" savetransfer program on the server side is not
executed.

Any other thing I can do to help you identify the problem ?


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=4163


cwlin@kingb.com.tw changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |major




------- Comment #3 from cwlin@kingb.com.tw  2006-10-12 04:53 MST -------
I think I know why it fails with ssh automatic key authentication.

I used the command option in the file "authorized_keys".
When it is set, sshd will ignore the the command supplied by the user (rsync,
in this case).
Instead, sshd will take the command specified in the "authorized_keys"
file.
Therefore, the option used by the server-side rsync is not the same as the
client -side one expects, which causes the checksum error.

The option "-vv" of "rsync" reveals the command sent to the
server.

Is it possible that the "rsync" provide a special option, which will
allow the
other options to be transferred like the data form the client to the server ?
In this way, the server-side rsync will not be mistaken by sshd.

Or some precautious statements in the document are enough ?


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=4163





------- Comment #4 from hashproduct+rsync@gmail.com  2006-10-12 15:22 MST
-------
(In reply to comment #3)
> Is it possible that the "rsync" provide a special option, which
will allow the
> other options to be transferred like the data form the client to the server
?
Yes, a single-use rsync daemon invoked over SSH does just this.  To set one up,
create an rsyncd.conf in the home directory of the account accessed over SSH,
and force the command "rsync --daemon --server ." in the
authorized_keys file.
If you want to put rsyncd.conf in a different directory X, then force the
command "cd X && rsync --daemon --server .".  Then you can
access the daemon
like this:

rsync -e "ssh -l sshuser" daemonuser@remote::module/path .

The "refuse options" setting in rsyncd.conf gives you lots of control
over what
options the daemon allows.  Thus, forcing an appropriately configured
single-use rsync daemon is almost always better than forcing a particular
server command.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=4163


cwlin@kingb.com.tw changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |INVALID




------- Comment #5 from cwlin@kingb.com.tw  2006-10-13 04:51 MST -------
Thanks so much for your illustration!

Rsync has already such a powerful option.
With the command "rsync --daemon --server --config=some_dir/rsyncd.conf
." in
the authorized_keys file on the server, 
the user on the client can issue different rsync commands to the server.
And the security remains if daemon configruation file "rsyncd.conf" is
properly
set.

Thanks again for providing such a great tool ^_^


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=4163





------- Comment #6 from wayned@samba.org  2006-10-15 11:23 MST -------
For completeness sake, I'll also mention that the rrsync script in the
support
directory is one way to run a forced-command ssh setup without resorting to
daemon mode: it parses the options and errors out if the options are not
acceptable, but it never changes the options, which can cause corruption in the
protocol.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.