décalage de la version du protocole -- votre Shell est-il propre ?

L'un de vos scripts de connexion (.bashrc/.cshrc/etc.) est probablement en train de sortir des données dans le terminal (alors qu'il ne devrait pas). Cela provoque une erreur de ssh lorsqu'il se connecte et se prépare à copier car il commence à recevoir des données supplémentaires qu'il n'attend pas. Supprimez la sortie qui est générée dans les scripts de démarrage.

Vous pouvez vérifier si votre terminal est interactif et ne sort que du texte en utilisant le code suivant dans un bashrc. Quelque chose d'équivalent existe aussi pour d'autres shells :

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

ou alternativement, comme ceci, puisque le paramètre spécial - contient i lorsque le Shell est interactif :

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

Pour plus d'informations, voir : rsync via ssh de linux vers Windows sbs 2003 non conforme au protocole

Pour diagnostiquer ce problème, assurez-vous que la sortie suivante est celle que vous obtenez lorsque vous vous connectez à l'hôte par ssh :

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

Si vous obtenez des nouvelles lignes ou d'autres données, vous savez qu'une sortie supplémentaire est envoyée. Vous pouvez renommer vos fichiers .bashrc/.cshrc/.profile/etc. en quelque chose d'autre afin qu'ils ne produisent pas de sortie supplémentaire. Bien sûr, il y a toujours des fichiers système qui peuvent causer cela. Dans ce cas, vérifiez avec votre administrateur système que les fichiers système ne produisent pas de données.

Dépannage de ce problème :

Il existe un moyen simple de tester si votre Shell est propre, pour une connexion ssh : exécutez une commande à partir de la connexion ssh, plutôt que de lancer une Shell interactive. Le site false se terminera immédiatement sans produire aucune sortie, c'est donc un bon test :

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

Si cette ligne de commande produit une sortie, un de vos scripts de démarrage est à blâmer :

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$

Une autre chose à vérifier si vous obtenez cette erreur est de savoir si rsync est installé et localisable par 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 n'est pas dans le chemin, vous verrez plutôt quelque chose comme :

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

Vous pouvez résoudre ce problème soit en installant rsync, soit, s'il est installé mais à un emplacement inhabituel, en passant l'emplacement à la ligne de commande rsync :

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

Ceci est généralement causé par votre Shell's login stuff output stuff on a non-interactive Shell. Vous pouvez tester si c'est le cas en faisant :

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

Si testfile n'est PAS 0 octet, alors le problème est que votre Shell sort quelque chose. Vérifiez /etc/profile , .profile , .bashrc , .cshrc etc. Si c'est le cas, vous pouvez le modifier pour qu'il vérifie si votre terminal est interactif et qu'il ne sorte que du texte en utilisant le code suivant dans un bashrc. Quelque chose d'équivalent existe également pour les autres shells :

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

ou alternativement, comme ceci, puisque le paramètre spécial - contient i lorsque le Shell est interactif :

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

Cependant, si le fichier de test est en fait 0 octet, alors votre Shell se comporte bien, mais il est possible que vous ayez simplement une très ancienne version de rsync. Vous pouvez dire à l'extrémité client (en supposant qu'il s'agit de l'extrémité la plus récente) de ne pas annoncer une version si élevée que l'ancienne version du serveur rsync ne la reconnaît pas. Vous pouvez le faire en utilisant l'option --protocol= option. Dans mon cas, l'utilisation de --protocol=30 a fait l'affaire.

Si vous avez toujours des problèmes, essayez de vous connecter en tant qu'utilisateur avec lequel rsysnc se connecte et essayez d'exécuter rsync --version pour voir si le Shell peut trouver rsync. Si vous obtenez quelque chose qui dit commande non trouvée, alors rsync pourrait ne pas être installé sur la machine à laquelle vous vous connectez ou il pourrait ne pas être dans le chemin. Rsync a des options pour spécifier le chemin de l'extrémité distante, lisez la ou les pages de manuel.

Il s'agit d'un cas particulier par rapport aux autres réponses, mais il n'est pas très différent de ces dernières.

Pour exécuter une rsync via ssh, vous avez besoin d'un accès Shell dans ssh pour exécuter la commande rsync à distance. Si votre compte ssh n'autorise que scp/sftp, vous ne pourrez pas lancer le rsync distant et échouera en donnant cette erreur.

Ceci peut être testé avec la même commande que ci-dessus

ssh remotehost false

Celui-ci devrait échouer et celui-là devrait être un succès.

sftp remotehost

Cela prouve que vous avez un accès sftp uniquement.

Si vous le souhaitez et si vous disposez des autorisations nécessaires, vous pouvez désactiver l'accès sftp uniquement pour cet utilisateur, en modifiant le fichier /etc/ssh/sshd_config et vérifier si match と forcecommand entrées.

Vous pouvez également consulter cette page poste

J'ai protocol version mismatch -- is your shell clean? tout simplement parce que je n'avais pas installé rsync sur la autre pas encore terminé. sudo yum install rsync a résolu le problème.