sftp donne une erreur: "Message reçu trop longtemps" et quelle en est la raison?

J'ai pu faire sftphier une boîte RHEL 5.4 (RedHat) et aujourd'hui je ne peux pas.

Le message est "Received message too long 778199411", et après une enquête, il était dû au fait que ma boîte RHEL .bashrcavait une ligne echo "running .bashrc"- ou faisait écho à quelque chose, je pense.

Alors, pourquoi l'impression d'une ligne affecterait-elle sftp? Cela ressemblait un peu à un problème de conception comme l'impression d'une ligne dans des .bashrctravaux dans d'autres situations telles que la connexion ou sshet il est assez difficile de localiser les sftpéchecs pour une raison aussi étrange.

La question est donc de savoir pourquoi l'impression d'une ligne provoque une telle erreur et si nous aimons toujours imprimer quelque chose .bashrc? (principalement pour voir quand ce fichier est obtenu / exécuté).

Il s'agit d'un problème de longue date. Je l'ai trouvé il y a dix ans lorsque j'ai dû mélanger la SSH commerciale au travail et la SSH ouverte à la maison. Je l'ai rencontré de nouveau aujourd'hui et j'ai trouvé ce message.

Si j'avais recherché "sftp / scp échoue mais ssh est OK", je me serais souvenu de la solution plus tôt!

En termes simples, .bashrc et .bash_profile etc. doivent être silencieux ou ils interfèrent avec le protocole de connexion sftp / scp.

Voir la FAQ open-SSH:

2.9 - sftp / scp échoue à la connexion, mais ssh est OK.

Au moins pour SFTP cela peut être corrigé en utilisant le internal-sftpsous - système, car cela ne lit pas .bashrcou /etc/motd.

Changez simplement le /etc/ssh/sshd_configfichier et changez le sous-système SFTP:

#Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem sftp internal-sftp

Et l'erreur a disparu.

Chaque réponse que j'ai vue n'importe où sur ce sujet prétend que c'est trop de sortie imprimée via /etc/motd, ou .bashrc, etc. Pas toujours vrai. Si vous avez un compte qui n'en a pas .bashrc, le /etc/motdest vide et la valeur par défaut .bashrcest minimale sans sortie imprimée VOUS POUVEZ TOUJOURS avoir le problème. Si vous avez un compte utilisateur avec un shell de /sbin/nologinou /bin/falsecette erreur se produira toujours.

Pourquoi voudriez-vous faire cela??? Si vous tentiez d'accorder à quelqu'un un emprisonnement root sftp, sans accès sécurisé, cela se produira.

Contournement: autorisez-les sshet mettez-les également dans une prison racine. C'est un problème auquel il faut s'attaquer ssh, il est beaucoup trop long à venir.

mettez simplement le suivant en haut de ~ / .bashrc sur le nom d'utilisateur de l'id sur la machine distante si cet id utilise bash

# If not running interactively, don't do anything and return early
[[ $- == *i* ]] || return  

qui sort simplement tôt du ~ / .bashrc au lieu de se procurer le fichier entier ... cela résout le fait de rendre silencieux .bashrc lorsque vous ne vous connectez pas à cet identifiant et que vous exécutez simplement votre scp ou sftp avec ce nom d'utilisateur comme identifiant distant ... pour citer @ Peter Scott dans une autre réponse: "En termes simples, .bashrc et .bash_profile, etc. doivent être silencieux ou ils interfèrent avec le protocole de connexion sftp / scp."

Alternativement, si cet identifiant distant utilise zsh, placez le suivant en haut de son ~ / .zshrc

# If not running interactively, don't do anything and return early
[[ -o interactive ]] || exit 0

Si le shell de votre machine distante n'utilise pas ~ / .bashrc, effectuez la modification ci-dessus dans le fichier ~ / .bashrc_profile ou ~ / .profile ou similaire pour l'adapter à votre shell sur cette boîte distante

Il peut y avoir une raison de plus. Sur RHEL 6 avec openssh-5.3p1-122.el6.x86_64, nous avons constaté qu'il se comporte mal lorsque LOCALE reste à "C". En cas de modification avec:

export LC_ALL="en_US.UTF-8"

Ensuite, sftp se comporte correctement. Dans le précédent openssh-5.3p1-118, nous n'avons pas rencontré un tel comportement, il s'agit probablement d'un bogue mineur dans cette version.

Dans mon cas, pour le faire fonctionner, j'avais besoin de désactiver le message de bienvenue d'Ubuntu.