これは、非常に多くのコンソール(Linux、Macなど)、および多くの異なるネットワークにある多くの異なるマシンで見られます。正確な理由を特定することはできません。これが発生する理由は次のとおりです。SSH経由でマシンにログインするだけです。何らかの理由で接続が切断された場合(簡単にするために、ネットワークケーブルが抜かれたとしましょう)、コンソールが永久にハングすることがあります。それ以外の場合は、親シェルに正常に終了します。
これが発生すると、とても煩わしいです(たとえば、コマンド履歴が失われます)。強制終了できる秘密のキーボードショートカットはありますか(Ctrl-CまたはCtrl-Dは機能しません)?とにかく、すべての実装にわたってこのランダムな「バグ」の理由は何ですか?
強制終了する「秘密の」キーボードショートカットがあります:〜)フリーズしたセッションから、次のキーを順番に押します。 Enter~. ティルダ(改行の後のみ)はsshクライアントによってエスケープシーケンスとして認識され、ピリオドはクライアントにそれ以上の労力なしにビジネスを終了するように指示します。
通信の問題での長時間のハング動作はバグではありません。SSHセッションは、反対側が戻ってくることを期待してハングアップしています。ネットワークが切断された場合、場合によっては数日後、SSHセッションを取り戻すことができます。もちろん、あきらめて上記のシーケンスで死ぬように具体的に指示できます。クライアントでキープアライブタイムアウトを設定するなど、さまざまなことを実行できます。これにより、一定時間アクティブなリンクがない場合は、独自にシャットダウンしますが、デフォルトの動作はそのままです。可能な限り接続されています!
編集:この割り込みキーのもう1つの便利なアプリケーションは、ローカルsshクライアントの注意を引き、バックグラウンドでローカルシェルに戻って1分間戻ることです。たとえば、履歴から何かを取得したい場合は、フォアグラウンドで使用します。リモートで作業し続けるために。 Enter~Ctrl+Z ローカルシェルのバックグラウンドジョブキューにsshクライアントを送信してから、通常どおりにfg
を戻してください。
編集:ネストされたSSHセッションを処理する場合、複数のチルダ文字を追加して、チェーン内のSSHセッションの1つだけを抜け出して、他のセッションは保持することができます。たとえば、3つのレベルにネストしている場合(つまり、ローカル->マシン1->マシン2->マシン3からssh) Enter~. ローカルセッションに戻ります。 Enter~~. Machine1に残ります。 Enter~~~. Machine2に残ります。これは、sshセッションを一時的にバックグラウンドに移動するなど、他のエスケープシーケンスでも機能します。上記は、ティルダを追加するだけで、あらゆるレベルのネストで機能します。
最後に、あなたは使うことができます Enter~? 使用可能なエスケープコマンドのヘルプメニューを印刷します。
TL; DR-サポートされているエスケープコマンドは、サポートされているエスケープシーケンスです。
~. - terminate connection (and any multiplexed sessions)
~B - send a BREAK to the remote system
~C - open a command line
~R - request rekey
~V/v - decrease/increase verbosity (LogLevel)
~^Z - suspend ssh
~# - list forwarded connections
~& - background ssh (when waiting for connections to terminate)
~? - this message
~~ - send the escape character by typing it twice
(Note that escapes are only recognized immediately after newline.)
SSHはキープアライブ機能を提供します。以下をローカルに追加します~/.ssh/config
(存在しない場合は作成):
ServerAliveInterval 15
ServerAliveCount 3
この設定により、セキュアトンネルを介して15秒ごとに送信されるキープアライブ信号が確立されます。 3回連続して失敗すると、SSHクライアントは終了します。
一部のシステム(macOS 10.14を含む)では、代わりに次のようにする必要があることに注意してください。
ServerAliveInterval 15
ServerAliveCountMax 3
Ask.ubuntuのこの回答から取得: https://askubuntu.com/a/29967/30266
ハングするのは、SSHではなくTCPの機能です。 TCP=が接続を使用しているアプリケーションに接続が存在しないことを通知しない限り、アプリケーションはTCPセッション/接続が切断されたことを知る方法がありません。各ホストの観点、TCPセッションはまだ確立された状態にあり、長いアイドル(データフローなし)セッションはRSTまたはの欠如以外に有効ではないことは言うまでもありません。 TCPキープアライブパケットへの応答(これは普遍的に実装されているわけではありません)。これは、SSHのバグではないようです。その動作は予想されます。
接続が適切にハングしている場合、キーを押す前に接続が既にハングしているため、マジックキーストロークは通過しません。クライアントに終了するように指示できますが、これはサーバー側に保持されている(または保持されていない)履歴には影響しません。
これは実際には質問に答えませんが、接続のハングの影響を減らすのに役立つ可能性があります。リモートで作業しているとき(そして通常はそうでないときでも)、screen
を実行します(またはbyobu
ラッパーを使用できるかどうかに応じて)、接続が切断された場合、セッションとそのすべての履歴が保持され、再接続したときに残した状態で使用できるようになります。
私の場合、問題は大きなMTUサイズでした。 NATを使用している場合は、ルーターのMTUを変更できますが、サーバーのMTUを変更します。
Sudo /sbin/ifconfig eth0 mtu 1036
Sudo /etc/init.d/networking restart
Windowsでは、このキーを増やすこともできます。
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"TcpMaxDataRetransmissions"=dword:00000010