sftp выдает ошибку: «получено слишком длинное сообщение» и в чем причина?

Я смог сделать sftpвчерашнюю коробку RHEL 5.4 (RedHat), а сегодня не могу.

Сообщение "Received message too long 778199411", и после некоторого расследования, это было из-за того, что у моей коробки RHEL .bashrcесть линия echo "running .bashrc"- или что-то повторяет вообще, я думаю.

Так почему же распечатка строки влияет sftp? Это было немного похоже на проблему дизайна, так как распечатка строки в .bashrcработах в других ситуациях, таких как вход в систему или ssh, было трудно отследить, когда sftpпроизошел сбой по такой странной причине.

Таким образом, вопрос в том, почему распечатка строки вызывает такую ​​ошибку, и что, если мы все еще хотели бы распечатать что-то в .bashrc? (в основном, чтобы увидеть, когда этот файл получен / выполнен).

Это давняя проблема. Я обнаружил это десять лет назад, когда мне впервые пришлось смешивать коммерческий SSH на работе и открытый SSH дома. Я столкнулся с этим сегодня снова и нашел этот пост.

Если бы я искал «sftp / scp fails, но с ssh все в порядке», мне бы скорее напомнили о решении!

Проще говоря, .bashrc, .bash_profile и т. Д. Должны молчать, или они мешают протоколу соединения sftp / scp.

Смотрите open-SSH FAQ:

2.9 - ошибка sftp / scp при соединении, но ssh в порядке.

По крайней мере, для SFTP это можно исправить с помощью internal-sftpподсистемы, поскольку она не читает .bashrcили /etc/motd.

Просто измените /etc/ssh/sshd_configфайл и измените подсистему SFTP:

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

И ошибка ушла.

В каждом ответе, который я видел где-либо на этом, все утверждается, что это слишком много печатных выводов через /etc/motd, или .bashrcи т. Д. Не всегда верно. Если у вас есть учетная запись , которая имеет не .bashrc, то /etc/motdпусто, и по умолчанию .bashrcявляется минимальным , не отпечатком ПОЗВОЛЯЮЩИХ иметь проблему. Если у вас есть учетная запись пользователя с оболочкой /sbin/nologinили /bin/falseэта ошибка все равно произойдет.

Зачем ты это делаешь ??? Если вы пытаетесь предоставить кому-либо root-jailed sftp, без доступа к защищенной оболочке это произойдет.

Обойти: разрешить sshи положить их в корневую тюрьму, а также. Это проблема, с которой нужно бороться ssh, она слишком долгая.

просто поместите следующее в верхнюю часть ~ / .bashrc для имени пользователя id на удаленной машине, если этот идентификатор использует bash

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

который просто рано выходит из ~ / .bashrc вместо поиска всего файла ... это решает отключение .bashrc, когда вы не входите под этим идентификатором и просто запускаете scp или sftp с этим именем пользователя в качестве удаленного идентификатора ... процитировать @Peter Scott в другом ответе: «Проще говоря, .bashrc, .bash_profile и т. д. должны молчать, или они мешают протоколу соединения sftp / scp».

В качестве альтернативы, если этот удаленный идентификатор использует zsh, поместите следующее в верхнюю часть его ~ / .zshrc

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

Если оболочка на вашей удаленной машине не использует ~ / .bashrc, сделайте вышеуказанное редактирование в файле ~ / .bashrc_profile или ~ / .profile или аналогичном, чтобы соответствовать вашей оболочке на этом удаленном блоке

Может быть еще одна причина. На RHEL 6 с openssh-5.3p1-122.el6.x86_64 мы обнаружили, что он ведет себя неправильно, когда LOCALE остается на "C". Когда изменено с:

export LC_ALL="en_US.UTF-8"

Тогда sftp ведет себя правильно. В предыдущем openssh-5.3p1-118 такого поведения не было, поэтому, вероятно, в этой сборке есть небольшая ошибка.

В моем случае, чтобы это работало, мне нужно было отключить приветственное сообщение Ubuntu.