Ошибка SFTP «Полученное сообщение слишком длинное» - PullRequest
Новая
       1

Ошибка SFTP «Полученное сообщение слишком длинное»

5 голосов
/ 24 ноября 2011

Я недавно пытался использовать sftp для доступа к моей Linux-системе, где я реализую собственную простую оболочку. И я настроил пользователей, кроме root, на использование моей оболочки по умолчанию (редактируя файл / etc / passwd). Тогда возникают проблемы, когда я пытаюсь получить доступ через sftp, я получаю сообщение «Слишком длинное полученное сообщение:», я искал решения, и одним из решений является изменение оболочки по умолчанию для этого пользователя обратно на обычную оболочку bash. Я попробовал так, и это сработало, проблема в том, что есть ли способ, которым я все еще могу использовать свою собственную оболочку и также позволить sftp пройти? Пожалуйста, ответьте мне более подробно, например, какой файл мне нужно отредактировать и т. Д. Заранее спасибо:)

Ответы [ 2 ]

16 голосов
/ 24 ноября 2011

Сконфигурируйте ваш сервер для использования внутреннего сервера sftp, добавив следующую директиву к /etc/ssh/sshd_config: 

Subsystem sftp internal-sftp

Таким образом, он не будет использовать пользовательскую оболочку для запуска программы сервера sftp.

2 голосов
/ 11 мая 2018

«Полученное сообщение слишком длинное» означает, что ваш SFTP-клиент получил неверные данные с SFTP-сервера. Типичная причина в том, что сценарии запуска оболочки на сервере (.bashrc, .profile, .cshrc и т. Д.) Выдают какой-то вывод, и ваш SFTP-клиент пытается проанализировать этот вывод как сообщение SFTP. Вы можете проверить это, выполнив команду: 

ssh user@remote 'echo hello'

Если при этом выдается какой-либо вывод, отличный от «hello», то этот вывод, вероятно, помешает правильной работе SFTP или SCP.

Как и в ответе Сальвы, вы можете избежать этого, настроив сервер SSH на использование internal-sftp для сеансов SFTP. Это позволяет избежать запуска вашей оболочки для сеансов SFTP. Это не поможет с SCP.

Другой способ исправить это - выполнить команды запуска оболочки, выяснить, что производит вывод, и предотвратить это во время неинтерактивных сеансов SSH. Один совет - проверить TTY перед запуском команд, которые выдают результат: 

if [ -t 1 ]; then
    # standard output is a TTY
    ...
fi
...