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.

Дивіться поширені запитання щодо відкритого SSH:

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ця помилка все-таки відбудеться.

Навіщо ти це зробив ??? Якщо ви намагалися дозволити комусь в'язницю sftpбез доступу захищеної оболонки, це станеться.

Пообіцяйте: дозвольте sshі покладіть їх також у кореневу в'язницю. Це проблема, яку потрібно вирішити ssh, це ще занадто довго.

просто поставте наступну поверх ~ / .bashrc на ім'я користувача id на віддаленій машині, якщо цей ідентифікатор використовує bash

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

який просто виходить рано з ~ / .bashrc замість пошуку всього файлу ... це вирішує зробити .bashrc мовчазним, коли ви не входите в цей ідентифікатор і просто запускаєте scp або sftp з цим ім'ям користувача як віддалений ідентифікатор ... цитую @ Петра Скотта в іншій відповіді: "Попросту кажучи, .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.