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)
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.
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 ?
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 ?
(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.
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 ^_^
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.
*** Bug 4560 has been marked as a duplicate of this bug. ***