☰

奇妙な SSH の問題、ssh は -t で動作しますが、それがないとフリーズします

tag-icon • tag-icon shell ssh login
奇妙な SSH の問題、ssh は -t で動作しますが、それがないとフリーズします

サーバーの 1 つにログインするとssh、ログインしたように見えますが、プロンプト ( message debug2: shell request accepted on channel 0 is the last log entry) が表示される前にハングします。

奇妙なことに、ssh -t "/bin/bash"機能するときもあれば機能sshしないときもあります。

これまでにわかったこと

  • 通常、同じ地理的位置にあるサーバーからは問題なくログインできます
  • もし私がssh -t '/bin/bash'- どこからでも完璧にログインできるなら。
  • もし私がrsync にサーバーは動作しているように見えますが、その後ロックされます
  • もし私がrsync からサーバーは問題なく動作します

私が試したこと

  • すべてのログインオプションを削除または変更する.profile、.bashrc /etc/profile
  • 変更するssh_config および/または sshd_config正常に動作する同一のサーバーから
  • ルーティングを確認しました
  • ネットワークの専門家に調べてもらいましたがtcpdump、効果はありませんでした（ただし、再送信が多数あるようです）

他に何も思いつかない

怪しいネットワーク カード ドライバー/ファームウェアは別として。

答え1

それはプロファイルの問題から来ている可能性があります。
接続すると、シェルは「ログイン」せず、ソースもソースssh -t /bin/bash も取得しません .../etc/profile~/.profile~/.bashrc

したがって、接続後、シェルをデバッグ モードにして、各ファイルをソースし、内部でブロックされているものを見つけます。

set -x 
. /etc/profile 
...and so on

編集

私が間違っていたことに注意してください。.bashrc ファイルは任意の対話型シェルによってソース化されます (したがって、ここでは profile、profile.d ファイルのみが重要です)。

接続プロセスのさまざまな段階のリストを作成してみてください。次のようなものです。

1) ssh 接続 (config、...)
2) ログイン (PAM、tty、wtmp、...)
3) シェルの起動 (プロファイル、ホーム ディレクトリ アクセス、...)

(1) を確認するには、sshd デーモンをデバッグ モードで起動します。そのためには、別の sshd を起動し、専用ポート (ポート 22 ではないため、通常の sshd デーモンを停止する必要はありません) を listen する必要があります。

# /usr/sbin/sshd -p 2222 -ddd

その sshd は 1 つの接続のみを受け入れ、バックグラウンドには入りません。別のターミナルを開いて、その ssh セッションに接続します。

# ssh -vvv -p 2222 user@host

受信したメッセージを同じブランドの別のサーバーのメッセージと比較することができます。そうすれば、問題が ssh 側にあるかどうかがわかります。

(-ddd と -vvv は最大デバッグ レベルです。調整できます)

わかったリンク、より詳細になります。

答え2

私の問題に対する答え 結局、ネットワークの問題であることがわかりました。最終的に、すべてのネットワーク カードの MTU を少し下げると、問題が解決することがわかりました。

おそらくそのネットワークの何かが誤って構成されているのでしょうが、今ではそれを証明してネットワーク チームに引き渡すことができます (彼らはサーバーの問題だと言い続けました)。

ただし、これは最後の手段であることに注意してください 私が経験した奇妙な点は、ssh サーバーが同じサブネットからは動作するがその外部からは動作せず、ssh -t '/bin/bash' がどこからでも動作したことです。

また、正常に開始する rsync もありましたが、ある時点でハングしたり、接続が切断されたりしました。

したがって、この回答をご覧になっている場合は、まず上記の他の回答を試してください。私のような異常が発生した場合のみ、これが役立つ可能性があります。

ご協力ありがとうございました。あらゆることを試し、多くのことを学びました。サーバーとは何の関係もないことが確認できました (まさに私が望んでいたことです)。

協力してくれた皆さんに感謝します

答え3

最近、ネストされた仮想化プラットフォームを使用したときにも同じ問題が発生しました。

ソース サーバーまたは宛先サーバーで MTU を 1500 から 1400 に減らすと機能します。

/sbin/ip link set dev eth0 mtu 1400

答え4

するとssh some_user@some_host /bin/bash、あなたがやっていることは、ユーザーのシェル/etc/passwd（ホスト/bin/bash) を実行し、そのシェル内から指定されたコマンド を実行します。

今、ユーザーのシェル（ でもあると仮定しましょうbash）は対話的に起動されていません（代わりに指定されたコマンドを実行しています）。そのため、pty（擬似端末) これは、発行されたコマンドが使用する pty がないため、非対話形式で開始されることを意味します。

この例では、要求された/bin/bashコマンドは起動されますが、ハングしているように見えます。

sshとにかく pty を作成して、シェルとその子プロセスで使用できるようにすることで、この問題を修正できます。これが-t実行する処理です。

    $ ssh -t some_user@some_host bash

コマンドに強制的に pty を作成させることでこれを修正することもできます。 の場合bash、引数を渡すことでこれを行います-i。次のコマンドラインも機能するはずです。

$ ssh some_user@some_host bash -i

ただし、後者の場合、シェルはアクセスできず/dev/tty、警告が表示されることに注意してください。

bash: no job control in this shell

その理由は次のように説明されているここシェルで何をする予定かによって、これが問題になる場合とならない場合がありますが、 を使用する方がssh -tおそらく良い選択肢です。

bash(いずれにしても、ユーザーのデフォルト シェルのパス上にあるはずなので、コマンドとして渡すだけでよいことに注意してください)

関連情報