sftpでエラーが発生します:「受信したメッセージが長すぎます」。理由は何ですか?


26

私はやることができたsftpRHEL 5.4ボックス(RedHatの)に昨日、今日私はできません。

メッセージは"Received message too long 778199411"であり、いくつかの調査の後、RHELボックスに.bashrc回線があるecho "running .bashrc"か、または何かがまったくエコーしていたためだと思います。

では、なぜ行の印刷が影響するのsftpでしょうか?.bashrcログインやその他の状況で作品の行を印刷するなど、設計上の問題のように感じました。また、このような奇妙な理由で失敗sshしたsftp場合、追跡するのは少し難しいです。

質問は、なぜ行を印刷するとそのようなエラーが発生するのか、それでも何かを印刷したい場合は.bashrcどうなるのか?(主に、このファイルがいつソース/実行されるかを確認します)。


回答:


26

これは長年の問題です。10年前、職場で商用のSSHと自宅でopen-SSHを最初に混ぜなければならなかったときに、それを見つけました。今日、私はそれに再び出くわし、この投稿を見つけました。

「sftp / scpは失敗するがsshは問題ありません」を検索していた場合、その解決策がすぐに思い出されました。

簡単に言えば、.bashrcや.bash_profileなどはサイレントにする必要があります。そうしないと、sftp / scp接続プロトコルに干渉します。

open-SSH FAQを参照してください。

2.9-sftp / scpは接続時に失敗しますが、sshは問題ありません。


自己更新シェルユーティリティは、この問題の良い犯人です。私にとっては、Jenkinsのdeploy-over-sshを妨害するRubyバージョンマネージャーであることがよくありました。
エリックP. 14

このおかげで、bashrcとbash_profileにあったいくつかのデバッグエコーステートメントを削除して、これを解決しました。
SgtPooki

3
間違った.bashrcはサイレントにする必要があります。.bash_profileは問題なくエコーできます。
クバンチク

2
ここに着陸した場合:serverfault.com/a/630714で示唆されているようssh yourhost /usr/bin/trueに、sshの出力をプローブするために使用できます。私の場合、〜/ .bashrcでエラーが発生し始めたコマンドが見つかりました。
ユヴァルアツモン

16

少なくとも、SFTPのために、これは使用して固定することができinternal-sftp読まないこととして、サブシステムを.bashrc/etc/motd

/etc/ssh/sshd_configファイルを変更し、SFTPサブシステムを変更するだけです。

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

そして、エラーはなくなりました。


私はこれが好きです。これがセキュリティに影響するかどうか疑問に思いますか?
RoyM

internal-sftpIMOは、SFTPサポートを提供するより良い方法です。あなたはこの関連の記事を見ることができます:serverfault.com/questions/660160/...
ケネス・

sshd_configの変更提案の後、sshdとsftpを殺しました(悪魔がいたかどうかはわかりません)。最初に受信メッセージが長すぎますというエラーが発生しましたが、とにかくログインしました。その後、同じ問題に戻ります
-clearlight

2

これに関するどこかで私が見たすべての応答は、、/etc/motdまたは.bashrcなどを介して印刷出力が多すぎると主張しています。アカウントにnoが.bashrcあり、/etc/motdが空で、デフォルト.bashrc最小限で、印刷出力がない場合でも、問題が発生する可能性があります。のシェルを持つユーザーアカウントがある場合、/sbin/nologinまたは/bin/falseこのエラーが引き続き発生します。

なぜこれを行うのですか??root-jailedを許可しようとした場合sftp、セキュアシェルアクセスなしでこれが起こります。

回避策:sshそれらを許可して、ルート刑務所に入れます。これはで対処する必要がある問題でありssh、到来するには長すぎます。


この問題は、.bashrcのカスタム出力が長すぎるために発生しました(そこにscreenfetchがあります)。しかし、私はまだそれがこれを無視作る方法を把握しよう
vladkras

はい、そうかもしれません。sshを変更する必要があります。私たちの場合、それはシェルの問題でした。実際にルートジェイル専用のsftpクライアントを使用したので、ルートジェイルのすべてを行う必要はありませんでした。
TekOps

ポイントは、.bashrcを変更したくないということです。任意の長さの最初のメッセージでサーバーに接続したい。したがって、おそらくIDEの設定を変更する必要があります
-vladkras

2

そのIDがbashを使用している場合、リモートマシン上のIDのユーザー名の〜/ .bashrcの先頭に次のように入力するだけです。

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

これは、ファイル全体をソースするのではなく〜/ .bashrcから早期に終了します...これにより、そのIDにログインせず、リモートIDとしてそのユーザー名でscpまたはsftpを実行しているときに.bashrcをサイレントにすることが解決されます...他の回答で@Peter Scottを引用する:「簡単に言えば、.bashrcや.bash_profileなどは黙っておかないと、sftp / scp接続プロトコルに干渉します。」

あるいは、そのリモートIDがzshを使用している場合は、〜/ .zshrcの先頭に次を配置します

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

リモートマシンのシェルが〜/ .bashrcを使用しない場合は、上記の編集をファイル〜/ .bashrc_profileまたは〜/ .profileなどで行い、そのリモートボックスのシェルに合わせます


1

もう1つの理由があります。openssh-5.3p1-122.el6.x86_64を使用したRHEL 6では、LOCALEが「C」のままであると動作がおかしいことがわかりました。変更時:

export LC_ALL="en_US.UTF-8"

その後、sftpは正しく動作します。以前のopenssh-5.3p1-118では、このような動作は発生していなかったため、おそらくこのビルドの小さなバグです。


1
この一見奇妙な提案が、私の状況に合ったものでした。ありがとう!
jwd630

0

私の場合、それを機能させるには、Ubuntuのウェルカムメッセージを無効にする必要がありました。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.