Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

When following the instructions to do rsync backups given here: http://troy.jdmz.net/rsync/index.html

I get the error "protocol version mismatch -- is your shell clean?"

I read somewhere that I needed to silence the prompt (PS1="") and motd (.hushlogin) displays to deal with this. I have done this, the prompt and login banner (MOTD) not longer appear, but the error still appears when I run:

rsync -avvvz -e "ssh -i /home/thisuser/cron/thishost-rsync-key" remoteuser@remotehost:/remote/dir /this/dir/

Both ssh client and sshd server are using version 2 of the protocol.

What could be the problem? Thanks.

[EDIT] I have found http://www.eng.cam.ac.uk/help/jpmg/ssh/authorized_keys_howto.html which directs that it is sometimes necessary to "Force v2 by using the -2 flag to ssh or slogin

 ssh -2 -i ~/.ssh/my_private_key remotemachine"

It is not clear this solved the problem as I think I put this change in AFTER the error changed but the fact is the error has evolved to something else. I'll update this when I learn more. And I will certainly try the suggestion to run this in an emacs shell - thank you.

share|improve this question
1  
Do your login scripts output something that's not immediately visible, for example a window title changing command? One way to check this is to run Emacs, type ESC x shell, and do export TERM=xterm; ssh remotehost ls. If any control characters or other spurious output appears, that's what you have to hunt down. –  Gilles May 6 '11 at 23:13
    
I was having the same problem. In my case the SSH server was configured to chroot users and to only allow SFTP access so it wasn't possible to run the rsync command from the remote shell. If you have access to the server check for the ForceCommand configuration option in /etc/ssh/sshd_config. If it's set to something that's the problem. –  devius Dec 13 '12 at 15:05
    
For the record, I've run into a situation where I just gave up with a protocol mismatch. rsync --version output identical on both hosts, interactive and non-interactive ssh completely silent, nothing fancy in authorized_keys... Just doesn't work. I leave this comment for others who are rabbibt holing. Do yourself a favour and try without --rsync-path. You'll probably find your problem has nothing to do with this SO. –  sheldonh Oct 30 '13 at 9:29

6 Answers 6

One of your login scripts (.bashrc/.cshrc/etc.) is probably outputting data to the terminal (when it shouldn't be). This is causing ssh to error when it is connecting and getting ready to copy as it starts receiving extra data it doesn't expect. Remove output that is generated in the startup scripts.

You can check if your terminal is interactive and only output text by using the following code in a bashrc. Something equivalent exists for other shells as well:

if shopt -q login_shell; then
    [any code that outputs text here]
fi

or alternatively, like this, since the special parameter - contains i when the shell is interactive:

if echo "$-" | grep i > /dev/null; then
    [any code that outputs text here]
fi

For more information see: rsync via ssh from linux to windows sbs 2003 protocol mismatch

To diagnose this, make sure that the following is the output you get when you ssh in to the host:

USER@HOSTNAME's password: 
Last login: Mon Nov  7 22:54:30 2011 from YOURIP
[USER@HOSTNAME ~]$ 

If you get any newlines or other data you know that extra output is being sent. You could rename your .bashrc/.cshrc/.profile/etc. files to something else so that they won't output extra output. Of course there is still system files that could cause this. In that case, check with your sysadmin that the system files don't output data.

share|improve this answer

There is a simple way to test if your shell is clean, for an ssh connection: run a command from the ssh connection, rather than starting an interactive shell. The false command will immediately terminate without producing any output, so it is a good test:

bash$ ssh remotehost false
Enter passphrase for key '/home/user/.ssh/my_private_key': 
bash$

If that command line produces any output, one of your startup scripts is to blame:

bash$ ssh remotehost false
Enter passphrase for key '/home/user/.ssh/my_private_key': 
Welcome to RemoteHost!

This system is company property and is provided for authorized use only, 
as set forth in applicable written policies. Unauthorized use is prohibited 
and may be subject to discipline, civil suit and criminal prosecution.

Welcome back - You last logged in 16 days ago...
bash$

Another thing to check if you are getting this error is whether rsync is installed and locatable by ssh:

bash$ ssh remotehost "rsync --version"
Enter passphrase for key '/home/user/.ssh/my_private_key': 
rsync  version 3.0.9  protocol version 30
Copyright (C) 1996-2011 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Capabilities:
    64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
    socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
    append, ACLs, xattrs, iconv, symtimes

rsync comes with ABSOLUTELY NO WARRANTY.  This is free software, and you
are welcome to redistribute it under certain conditions.  See the GNU
General Public Licence for details.
bash$

If rsync is not in the path, you will instead see something like:

bash$ ssh remotehost "rsync --version"
Enter passphrase for key '/home/user/.ssh/my_private_key': 
bash: rsync: command not found
bash$

You can fix this by either installing rsync, or if it is installed but in an unusual location, passing the location to the rsync command line:

rsync -avvvz -e "ssh -i /home/thisuser/cron/thishost-rsync-key" \
    --rsync-path="/usr/local/bin/rsync" \
    remoteuser@remotehost:/remote/dir /this/dir/
share|improve this answer

The prompt will not be shown at all when directly executing a command, and non-interactively so. A simple google turns up first result: http://marc.info/?l=rsync&m=100263876212594&w=2 And since the shell can potentially be invoked, it must not display anything in non-interactive mode — like, when typing just "bash" into an existing prompt, nothing but the new prompt should appear.

share|improve this answer
    
Perhaps I did not make it sufficiently clear but I have already done this "prompt (PS1="") and motd (.hushlogin)". The login indeed does not show any prompt. Despite this the protocol mismatch error still appears. Thanks though - much appreciate the suggestion. –  rfreytag May 6 '11 at 22:09
    
You basically mentioned this already, but I've had problems like this if there is anything in the .bashrc (or other profile script) that echos anything to the screen. I've even had this kind of problem when running certain programs in the shell that changes things in a certain way (for example, I wasn't able to change my shell with chsh, so I had my .cshrc run bash to change my shell, and ssh wouldn't work anymore). –  lsd May 6 '11 at 23:02
    
Well that is certainly interesting. I wonder how I might diagnose this since executing the rsync command interactively shows nothing echoed to the screen and the login is completely silent? Hmmm...I wonder if there is something amiss with the shell as you suggest. Thanks. –  rfreytag May 7 '11 at 1:30

This can be caused by an login message on the remote host such as "Your password is going to expire in 6 days" which RSYNC does not expect

share|improve this answer

This is commonly caused by your shell's login stuff outputting stuff on a non-interactive shell. You can test if this is the case by doing:

ssh username@host "/bin/true" > testfile
ls -l testfile

If testfile is NOT 0 bytes, then the trouble is that your shell is outputting something. Check /etc/profile, .profile, .bashrc, .cshrc, etc. If it is, you can change it to check if your terminal is interactive and only output text by using the following code in a bashrc. Something equivalent exists for other shells as well:

if shopt -q login_shell; then
    [any code that outputs text here]
fi

or alternatively, like this, since the special parameter - contains i when the shell is interactive:

if echo "$-" | grep i > /dev/null; then
    [any code that outputs text here]
fi

However, if the test file is in fact 0 bytes, then your shell is behaving, but it is possible that you just have a very old version of rsync. You can tell the client end (assuming it is the newer end) to not advertise such a high version that the old rysnc server version doesn't recognize it. You can do this using the --protocol= option. In my case, using --protocol=30 did the trick.

If you are still having trouble, try ssh in as the user rsysnc is connecting with and try running rsync --version to see if the shell can find rsync. If you get something that says command not found, then rsync might not be installed on the machine you are connecting to or it might not be in the path. Rsync does have options for specifying the path of the remote end, read the man page(s).

share|improve this answer

This is a special case from the other replies, but is not very different from then.

To execute a rsync via ssh, you need shell access in ssh to execute the remote rsync command. If your ssh account only allows scp/sftp, you will not be able to start the remove rsync and fails giving this error.

This can be tested with the same command as above

ssh remotehost false

This one should fail and this one should be success

sftp remotehost

This proves that you have a sftp only access.

If you want and have permissions to do so, you can disable the sftp only access for that user, by editing the /etc/ssh/sshd_config and check for match and forcecommand entries.

You can also check this post

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.