The problem / error: When doing an rsync over ssh file transfer I get this error.

Sidenote: The options -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null, so that I dont get that Host Key authentication warning. More info on that here… Ignoring SSH Authenticity 

The biggest issue is that the file/s transfer didnt work. Nothing transfered.

What am I supposed to see? Instead of the above im’ supposed to see a completed transfer.

The solution: One good source on it:

The solution in my words:

To fix that login to the remote ssh server to which your rsyncing to (in my case ) and check out all of the scripts that launch when you login. Make sure none of them output to the screen.

So on your remote server check out your /etc/ssh/sshrc, ~/.bashrc, .profile files (all of the files that get ran upon a new ssh connection) and make sure none of them output to the screen (stderr might be okay im not sure, havent tested.)

For example if you follow my guide on having SSHRC output some nice things when you login to screen and to the file, then you will get this error (because it outputs to the screen, the output to the files is fine). To avoid that, comment out anything that outputs on the screen (all of the echo and top and df commands). Things that save to a file are fine and will not cause an error.

A few ways to test if you will get the protocol mismatch error.

(1) One way is to run rsync over ssh and see if you get the error.

(2) Favorite way to test if error will happen is by running rsh (method described in link above). It create this file from the output of rsh running /bin/true. Analyzing the size will let you know if you will get the error. If is bigger than 0 bytes, its not empty, its not clean, thus you will get the error. If its 0 byte, meaning its empty, then its clean and you will not get the error.

FORMAT: rsh server /bin/true >

SIDENOTE: will have the output of whatever those ssh startup scripts put on the screen. so you can analyze what it contains to hint at what you need to clean up.

SIDENOTE: echos are not the only thing that output to screen. Any command can potentially output to the screen. ex: top, ps, df, free, etc…

(3) Another way is to login to the ssh session and analyze the output you get between your ssh command and your prompt once you connect. Some of the output is fine and can be ignored (such as the banner of the data Welcome to someserver, and the Last login:… as they were not caused by those startup scripts but caused by default login scripts – the reason they are okay is that when you run rsync or rsh those scripts dont run, message of the day is not displayed, and Last Login is not displayed as well)

For example this output doesnt cause the above error, because its not caused by the ssh scripts (below messages are output by things like message of the day, motd, and the like):

SIDENOTE: for the above the rsh command from (2) was 0 bytes and empty, thus error will not occur

Below ssh connection output hints that the protocol mismatch error will happen. Its extra output that we normally dont see upon connection (normal output is like you see above).

SIDENOTE: here is what the rsh command would show in that file, this will hint us at what to look at on the remote server (someserver in this example) to fix the problem. This output hints me that its all output that was caused by the sshrc file so I will go ahead and clean up the output by commenting anything that outputs to the screen.

Do I need to have a clean shell on both sides of the connection?

No. You only need to have a clean shell on the side your connecting to. So in the examples above. Its okay if firstserver (the one we are running the rsync command on) doesn’t have a clean shell, so when you connect via ssh to firstserver, its fine if it has extra stuff printed. However someserver (the remote server we are copying to) does need to have a clean shell.

Other options

You can circumnavigate this issue all together by using things other than rsync thru ssh, that way you dont have change any files on the server and still get your desired files transfered.
If you copy the file via scp you might be okay. I verified that your good to go if you copy the file with a cat | ssh method
cat file | ssh -p 22
Also you could use other file transfer methods: ftp, sftp, regular rsync, samba, nfs, afp, the list goes on.

Leave a Reply

Your email address will not be published. Required fields are marked *