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

いつssh私のサーバの1つに、（私にプロンプトを与える前にハングアップし、その後にログインするようだが、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同じサーバーからの1つに変更する
• ルーティングを確認しました
• ネットワークの専門家にtcpdump役に立たなかった（多くの再送信があるようだが）

本当に何も考えられない

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

これは、プロファイルの問題に起因する可能性があります。 シェルに
接続するとssh -t /bin/bash「ログイン」されず、ソース/etc/profileも~/.profileandも ~/.bashrc...

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

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

編集

私が間違っていたことに注意してください。.bashrcファイルは、任意の対話型シェルによって供給されます（したがって、プロファイル、profile.dファイルのみがここで重要です）。

接続プロセスのさまざまなフェーズのリストを作成してみてください。このようなもの

1）ssh接続（config、...）
2）ログイン（PAM、tty、wtmp、...）
3）シェルの開始（profile、home dir access、...）

（1）を確認するには、sshdデーモンをデバッグモードで起動できます。そのためには、専用ポート（ポート22ではなく、通常のsshdデーモンを停止する必要はありません）をリッスンして、別のsshdを開始する必要があります。

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

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

# ssh -vvv -p 2222 user@host

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

（-dddおよび-vvvは最大デバッグレベルです。これを調整できます）

私はそのリンクを取得しました、より詳細に。

私の問題への答え は、ネットワークの問題であることが判明しました。最終的に、すべてのネットワークカードのMTUを少し落とすことで、問題がなくなることがわかりました。

ほとんどの場合、そのネットワークに対して何かが誤って設定されていますが、それを証明してネットワークチームに引き渡すことができます（サーバーチームの問題だと言われ続けました）。

ただし、これは最後の手段であることに注意してください。 私が持っていた特殊性は、sshサーバーが同じサブネットから機能し、外部からは機能せず、ssh -t '/ bin / bash'はどこからでも機能することでした。

また、正常に開始するrsyncがありましたが、ある時点でハングするか、接続をドロップします。

したがって、この答えを見ている場合は、上記の他のものを最初に試してみてください。私のような奇妙なことがある場合にのみ、これが役立つ可能性があります。

すべての助けに感謝します。私はすべてを試してみましたが、それは私に負荷を教え、それがサーバーとは何の関係もないことを確認させてくれました（これは私が望んでいたすべてです）。

助けてくれた皆さんに感謝します

行うときssh some_user@some_host /bin/bash、あなたがしていることはsome_userのシェル（some_hostで定義され/etc/passwdている）を起動し/bin/bash、そのシェル内から与えられたコマンドを実行することです。

現在、some_userのシェル（であると仮定しましょう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とにかくユーザーのデフォルトシェルのパス上にある必要があるため、コマンドとして渡すことができることに注意してください）

最近ネストされた仮想化プラットフォームを使用したとき、私は同じ問題を抱えています。

送信元サーバーまたは送信先サーバーでMTUを1500から1400に減らした後に機能します。

/sbin/ip link set dev eth0 mtu 1400