no coinciden las versiones del protocolo: ¿está limpio su shell?

Al seguir las instrucciones para hacer copias de seguridad de rsync aquí: http://troy.jdmz.net/rsync/index.html

Me aparece el error "la versión del protocolo no coincide - ¿está limpio su shell?"

Leí en alguna parte que necesitaba silenciar las indicaciones (PS1 = "") y motd (.hushlogin) para solucionar esto. He hecho esto, el aviso y el banner de inicio de sesión (MOTD) ya no aparecen, pero el error aún aparece cuando ejecuto:

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

Tanto el cliente ssh como el servidor sshd están utilizando la versión 2 del protocolo.

¿Cual podría ser el problema? Gracias.

[EDITAR] He encontrado http://www.eng.cam.ac.uk/help/jpmg/ssh/authorized_keys_howto.html que indica que a veces es necesario "Forzar v2 usando la bandera -2 para ssh o slogin

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

No está claro que esto resolvió el problema, ya que creo que puse este cambio DESPUÉS de que el error cambió, pero el hecho es que el error ha evolucionado a otra cosa. Actualizaré esto cuando sepa más. Y ciertamente intentaré la sugerencia de ejecutar esto en un shell de emacs - gracias.

Probablemente uno de sus scripts de inicio de sesión (.bashrc / .cshrc / etc.) Esté enviando datos al terminal (cuando no debería estarlo). Esto está causando un error de ssh cuando se conecta y se prepara para copiar, ya que comienza a recibir datos adicionales que no espera. Elimine la salida que se genera en los scripts de inicio.

Puede verificar si su terminal es interactiva y solo genera texto utilizando el siguiente código en un bashrc. También existe algo equivalente para otros proyectiles:

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

o alternativamente, así, ya que el parámetro especial -contiene icuando el shell es interactivo:

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

Para obtener más información, consulte: rsync a través de ssh de Linux a Windows sbs 2003 no coincide el protocolo

Para diagnosticar esto, asegúrese de que el siguiente es el resultado que obtiene cuando ingresa al host:

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

Si obtiene nuevas líneas u otros datos, sabe que se está enviando una salida adicional. Puede cambiar el nombre de su .bashrc / .cshrc / .profile / etc. archivos a otra cosa para que no generen salida adicional. Por supuesto, todavía hay archivos del sistema que podrían causar esto. En ese caso, verifique con su administrador de sistemas que los archivos del sistema no generen datos.

Hay una manera simple de probar si su shell está limpio, para una conexión ssh: ejecute un comando desde la conexión ssh, en lugar de iniciar un shell interactivo. El falsecomando terminará inmediatamente sin producir ningún resultado, por lo que es una buena prueba:

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

Si esa línea de comando produce algún resultado, uno de los scripts de inicio es el culpable:

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$

Otra cosa para verificar si está recibiendo este error es si rsync está instalado y localizable por 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$

Si rsync no está en la ruta, verá algo como:

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

Puede solucionar esto instalando rsync, o si está instalado pero en una ubicación inusual, pasando la ubicación a la línea de comando rsync:

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

Esto es comúnmente causado por las cosas de inicio de sesión de su shell que generan cosas en un shell no interactivo. Puede probar si este es el caso haciendo:

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

Si testfile NO tiene 0 bytes, entonces el problema es que su shell está generando algo. Comprobar /etc/profile, .profile, .bashrc, .cshrc, etc. Si es así, usted puede cambiar para comprobar si su terminal es de texto interactivo y sólo de salida al utilizar el código siguiente en un bashrc. También existe algo equivalente para otros proyectiles:

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

o alternativamente, así, ya que el parámetro especial -contiene icuando el shell es interactivo:

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

Sin embargo, si el archivo de prueba es de hecho 0 bytes, entonces su shell se está comportando, pero es posible que solo tenga una versión muy antigua de rsync. Puede decirle al cliente que finaliza (suponiendo que sea el último) que no anuncie una versión tan alta que la versión anterior del servidor rysnc no la reconozca. Puedes hacer esto usando la --protocol=opción. En mi caso, usar --protocol=30hizo el truco.

Si todavía tiene problemas, intente ssh mientras el usuario rsysnc se está conectando e intente ejecutar rsync --versionpara ver si el shell puede encontrar rsync. Si obtiene algo que dice que no se encontró el comando, es posible que rsync no esté instalado en la máquina a la que se está conectando o que no esté en la ruta. Rsync tiene opciones para especificar la ruta del extremo remoto, lea las páginas de manual.

Este es un caso especial de las otras respuestas, pero no es muy diferente de entonces.

Para ejecutar un rsync a través de ssh, necesita acceso de shell en ssh para ejecutar el comando remoto rsync. Si su cuenta ssh solo permite scp / sftp, no podrá iniciar la eliminación de rsync y falla al dar este error.

Esto se puede probar con el mismo comando que el anterior

ssh remotehost false

Este debería fallar y este debería ser un éxito

sftp remotehost

Esto demuestra que tiene un acceso solo sftp.

Si quieren y tienen permisos para hacerlo, puede desactivar la SFTP único acceso para ese usuario, mediante la modificación del /etc/ssh/sshd_configvehículo y verifique match y forcecommandentradas.

También puedes consultar esta publicación

Obtuve protocol version mismatch -- is your shell clean?simplemente porque todavía no había instalado rsync en el otro extremo. sudo yum install rsyncresuelve el problema.

La solicitud no se mostrará en absoluto cuando se ejecute directamente un comando, y no de forma interactiva. Un simple google muestra el primer resultado: http://marc.info/?l=rsync&m=100263876212594&w=2 Y dado que el shell puede ser invocado, no debe mostrar nada en modo no interactivo, como cuando escribe " bash "en una solicitud existente, no debería aparecer nada más que la nueva solicitud.

Esto puede deberse a un mensaje de inicio de sesión en el host remoto, como "Su contraseña caducará en 6 días" que RSYNC no espera