Lorsque vous suivez les instructions pour effectuer des sauvegardes rsync données ici: http://troy.jdmz.net/rsync/index.html
J'obtiens l'erreur "Non-correspondance de version de protocole - votre Shell est-il propre?"
J'ai lu quelque part que j'avais besoin de faire taire les affichages Invite (PS1 = "") et motd (.hushlogin) pour y faire face. J'ai fait cela, la bannière d'invite et de connexion (MOTD) n'apparaît plus, mais l'erreur apparaît toujours lorsque je lance:
rsync -avvvz -e "ssh -i /home/thisuser/cron/thishost-rsync-key" remoteuser@remotehost:/remote/dir /this/dir/
Le client ssh et le serveur sshd utilisent la version 2 du protocole.
Quel pourrait être le problème? Merci.
[EDIT] J'ai trouvé http://www.eng.cam.ac.uk/help/jpmg/ssh/authorized_keys_howto.html qui indique qu'il est parfois nécessaire de "Forcer v2 en utilisant le -2 drapeau à ssh ou slogin
ssh -2 -i ~/.ssh/my_private_key remotemachine"
Il n'est pas clair que cela ait résolu le problème car je pense que j'ai mis ce changement APRÈS que l'erreur a changé, mais le fait est que l'erreur a évolué vers autre chose. Je le mettrai à jour lorsque j'en apprendrai plus. Et je vais certainement essayer la suggestion de l'exécuter dans un shell emacs - merci.
L'un de vos scripts de connexion (.bashrc/.cshrc/etc.) Génère probablement des données sur le terminal (alors qu'elles ne devraient pas l'être). Cela provoque une erreur ssh lorsqu'il se connecte et se prépare à copier car il commence à recevoir des données supplémentaires auxquelles il ne s'attend pas. Supprimez la sortie générée dans les scripts de démarrage.
Vous pouvez vérifier si votre terminal est interactif et produire uniquement du texte en utilisant le code suivant dans un bashrc. Quelque chose d'équivalent existe également pour d'autres coquilles:
if shopt -q login_Shell; then
[any code that outputs text here]
fi
ou bien, 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 à Windows SBS 2003 incompatibilité du protocole
Pour diagnostiquer cela, assurez-vous que ce qui suit est la sortie que vous obtenez lorsque vous vous connectez à l'hôte:
USER@HOSTNAME's password:
Last login: Mon Nov 7 22:54:30 2011 from YOURIP
[USER@HOSTNAME ~]$
Si vous obtenez des retours à la ligne ou d'autres données, vous savez qu'une sortie supplémentaire est envoyée. Vous pouvez renommer votre .bashrc/.cshrc/.profile/etc. fichiers vers autre chose afin qu'ils ne produisent pas de sortie supplémentaire. Bien sûr, il existe encore des fichiers système qui pourraient provoquer cela. Dans ce cas, vérifiez auprès de votre administrateur système que les fichiers système ne produisent pas de données.
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 démarrer un shell interactif. La commande false
se terminera immédiatement sans produire de 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, l'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 à la place 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 en installant rsync, ou s'il est installé mais dans 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/
Cela est généralement dû au fait que les informations de connexion de votre shell produisent des informations sur un shell non interactif. Vous pouvez tester si c'est le cas en faisant:
ssh username@Host "/bin/true" > testfile
ls -l testfile
Si le fichier de test n'est PAS de 0 octet, le problème est que votre shell génère quelque chose. Vérifier /etc/profile
, .profile
, .bashrc
, .cshrc
, etc. Si tel est le cas, vous pouvez le modifier pour vérifier si votre terminal est interactif et afficher uniquement du texte en utilisant le code suivant dans un bashrc. Quelque chose d'équivalent existe également pour d'autres coquilles:
if shopt -q login_Shell; then
[any code that outputs text here]
fi
ou bien, 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 de 0 octet, alors votre Shell se comporte, mais il est possible que vous n'ayez qu'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 rysnc ne la reconnaît pas. Vous pouvez le faire en utilisant le --protocol=
option. Dans mon cas, en utilisant --protocol=30
a fait l'affaire.
Si vous rencontrez toujours des problèmes, essayez ssh in pendant que l'utilisateur 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 que la commande est introuvable, alors rsync peut ne pas être installé sur la machine à laquelle vous vous connectez ou il peut ne pas se trouver sur le chemin. Rsync a des options pour spécifier le chemin de l'extrémité distante, lisez les pages de manuel.
J'ai eu protocol version mismatch -- is your Shell clean?
simplement parce que je n'avais pas encore installé rsync à la fin autre. Sudo yum install rsync
résolu le problème.
Il s'agit d'un cas particulier des autres réponses, mais il n'est pas très différent de celui-là.
Pour exécuter un rsync via ssh, vous avez besoin d'un accès Shell dans ssh pour exécuter la commande rsync distante. Si votre compte ssh autorise uniquement scp/sftp, vous ne pourrez pas démarrer la suppression de rsync et échouera à donner cette erreur.
Cela peut être testé avec la même commande que ci-dessus
ssh remotehost false
Celui-ci devrait échouer et celui-ci devrait être un succès
sftp remotehost
Cela prouve que vous ne disposez que d'un accès sftp.
Si vous le souhaitez et disposez des autorisations nécessaires, vous pouvez désactiver l'accès sftp uniquement pour cet utilisateur, en modifiant le /etc/ssh/sshd_config
et recherchez les entrées match
et forcecommand
.
Vous pouvez également vérifier cela post
L'invite ne sera pas du tout affichée lors de l'exécution directe d'une commande, et de manière non interactive. Un simple google affiche le premier résultat: http://marc.info/?l=rsync&m=100263876212594&w=2 Et puisque le shell peut potentiellement être invoqué, il ne doit rien afficher en mode non interactif - comme si vous tapiez simplement "bash" dans une invite existante, rien que la nouvelle invite ne devrait apparaître.
Cela peut être dû à un message de connexion sur l'hôte distant tel que "Votre mot de passe va expirer dans 6 jours" auquel RSYNC ne s'attend pas
J'observe également cette erreur lors de l'extraction de fichiers d'une instance avec rsync version 2.5.7 protocol version 26
à version 3.1.1
:
protocol version mismatch - is your Shell clean?
(see the rsync man page for an explanation)
rsync error: protocol incompatibility (code 2) at compat.c(62)
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [Receiver=3.1.1]
Mais le shell distant n'avait pas de bannière de connexion. Au lieu de cela, la solution était de spécifier un protocole plus ancien ( ref ):
rsync --protocol=29 ...