The problem / error: When doing an rsync over ssh file transfer I get this error.
# rsync -avhP -e "ssh -p 22 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" file root@someserver.com:file Warning: Permanently added '[root@someserver.com]:22,[24.155.888.155]:2022' (ECDSA) to the list of known hosts. protocol version mismatch -- is your shell clean? (see the rsync man page for an explanation)
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
# rsync -e "ssh" file root@someserver.com:file Warning: Permanently added '[root@someserver.com]:22,[24.155.888.155]:2022' (ECDSA) to the list of known hosts. protocol version mismatch -- is your shell clean? (see the rsync man page for an explanation)
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: http://derpturkey.com/wtf-protocol-version-mismatch-is-your-shell-clean/
The solution in my words:
To fix that login to the remote ssh server to which your rsyncing to (in my case someserver.com ) 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.)
echo "hello" ## bad, will get error echo "hello" > somefile ## good, will not get error
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 out.data file from the output of rsh running /bin/true. Analyzing the size will let you know if you will get the error. If out.data 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 > out.data
rsh root@someserver.com -p 2022 /bin/true > out.data ls -lisah out.data # if file is 0 byte, your good to go, your shell is clean, you will not get the protocol version mismatch error # if file is > 0 byte, you will get the protocol version mismatch error.
SIDENOTE: out.data 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):
root@firstserver:~# ssh -p 2022 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null root@someserver.com Warning: Permanently added '[root@someserver.com]:22,[24.155.888.155]:2022' (ECDSA) to the list of known hosts. Welcome to someserver. Last login: Mon Feb 15 00:42:41 2016 from 10.10.10.111 root@someserver:~#
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).
root@firstserver:~# ssh -p 2022 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null root@someserver.com Warning: Permanently added '[root@someserver.com]:22,[24.155.888.155]:2022' (ECDSA) to the list of known hosts. Welcome to someserver. Last login: Mon Feb 15 00:52:44 2016 from firstserver ### Disk Usage: ### Filesystem Size Used Avail Use% Mounted on /dev/md0 4.0G 735M 3.1G 20% / /dev/md300 19T 16T 3.1T 84% /data ### Top Info: ### top - 00:58:57 up 15:34, 2 users, load average: 1.90, 1.79, 1.86 Tasks: 171 total, 1 running, 170 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.1 us, 19.0 sy, 2.8 ni, 71.6 id, 5.4 wa, 0.0 hi, 1.0 si, 0.0 st KiB Mem: 1015144 total, 983144 used, 32000 free, 636 buffers KiB Swap: 2093052 total, 0 used, 2093052 free, 304684 cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1 root 20 0 45816 3492 804 S 0.0 0.3 0:01.38 /sbin/init 2 root 20 0 0 0 0 S 0.0 0.0 0:00.01 [kthreadd] 3 root 20 0 0 0 0 S 0.0 0.0 0:47.12 [ksoftirqd/0] 5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 [kworker/0:0H] 7 root 20 0 0 0 0 S 0.0 0.0 0:20.63 [rcu_sched] 8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [rcu_bh] 9 root rt 0 0 0 0 S 0.0 0.0 0:00.07 [migration/0] ### Quick Info: ### * uname: Linux someserver 4.1.16.x86_64.1 #1 SMP Tue Jan 26 10:06:20 PST 2016 x86_64 GNU/Linux * uptime/uptime: 56077.76 81349.00 - 00:58:57 up 15:34, 2 users, load average: 1.90, 1.79, 1.86 * memory: total used free shared buffers cached Mem: 991 959 31 0 0 297 -/+ buffers/cache: 661 329 Swap: 2043 0 2043 Total: 3035 959 2075 -----Session start---- root@someserver:~#
SIDENOTE: here is what the rsh command would show in that out.data 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.
######################################################################
## EXAMPLE of a clean shell ##
## 0 byte output with out.data ##
## will not get protocol mismatch error when running rsync thru ssh ##
######################################################################
root@firstserver:~# rsh root@someserver.com -p 22 /bin/true > out.dat
root@firstserver:~# cat out.dat
root@firstserver:~#
## * NOTE: ls -l shows me the size of out.dat is 0 bytes
######################################################################
## EXAMPLE of a none clean shell ##
## none 0 byte output ##
## will get protocol mismatch error when running rsync thru ssh ##
######################################################################
root@firstserver:~# rsh root@forge.infotinks.com -p 22 /bin/true > out.dat
root@firstserver:~# cat out.dat
### Disk Usage: ###
Filesystem Size Used Avail Use% Mounted on
/dev/md0 4.0G 735M 3.1G 20% /
/dev/md300 19T 16T 3.1T 84% /data
### Top Info: ###
top - 01:39:33 up 16:15, 1 user, load average: 1.32, 1.72, 1.85
Tasks: 174 total, 1 running, 173 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.2 us, 18.3 sy, 2.9 ni, 72.0 id, 5.7 wa, 0.0 hi, 1.0 si, 0.0 st
KiB Mem: 1015144 total, 978036 used, 37108 free, 636 buffers
KiB Swap: 2093052 total, 0 used, 2093052 free, 302448 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 20 0 45816 4368 1680 S 0.0 0.4 0:01.39 /sbin/init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.01 [kthreadd]
3 root 20 0 0 0 0 S 0.0 0.0 0:47.51 [ksoftirqd/0]
5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 [kworker/0:0H]
7 root 20 0 0 0 0 S 0.0 0.0 0:21.43 [rcu_sched]
8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [rcu_bh]
9 root rt 0 0 0 0 S 0.0 0.0 0:00.07 [migration/0]
### Quick Info: ###
* uname: Linux someserver 4.1.16.x86_64.1 #1 SMP Tue Jan 26 10:06:20 PST 2016 x86_64 GNU/Linux
* uptime/uptime: 58514.07 85304.64 - 01:39:33 up 16:15, 1 user, load average: 1.32, 1.72, 1.85
* memory: total used free shared buffers cached
Mem: 991 954 36 0 0 295
-/+ buffers/cache: 658 332
Swap: 2043 0 2043
Total: 3035 954 2080
-----Session start----
## * NOTE: ls -l shows me the size of out.dat is bigger than 0 bytes (obviously as it has output)
## * NOTE: the above output can be helpful in finding what causes the shell to be dirty. I can search my start up scripts to see what outputs "Disk Usage" and "Top Info" and "-----Session start----" etc... Then I can clean that up.
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.