簡単な説明
何年もの間、SSH 接続で奇妙な動作が見られていましたが、今日まで質問しようとは考えていませんでした。これについていろいろ調べてみましたが、理由は見つかりませんでした。
環境
- 基本的に、さまざまなリージョン (アイルランド、ムンバイなど) でさまざまな AWS EC2 インスタンスを実行しています。
- 私はMacを持っています。
- そして、私はインドに住んでいます（何らかの理由で誰かに衝撃を与える場合に備えて）。
問題ステートメント 1
私の Mac が 4G ネットワーク経由でパーソナル ホットスポット (Samsung デバイスまたは iPhone から) に接続されている場合、SSH セッションで作業しないと (基本的に SSH 接続は理想的でした)、数分 (3 分以内) 後に SSH 接続がフリーズします。そのため、接続を維持するために矢印キーを押し続ける必要があります。
問題ステートメント 2 (これは問題ではありません)
しかし、Mac が Wi-Fi ブロードバンド接続に接続されている場合、この問題は発生しません。Mac をスリープ状態から復帰させた後 (蓋を開けた後) でも、SSH 接続は数時間接続されたままになります。
今日もグーグルで検索してみたところ、次のようなオプションを使用する解決策を示すさまざまな記事が見つかりましTCPKeepAliveたServerAliveInterval。
- sshd_config のオプション `ServerAliveInterval` と `ClientAliveInterval` は具体的に何をするのでしょうか?
- tcp-keepalive は ssh でどのように機能しますか?
- https://raspberrypi.stackexchange.com/questions/8311/ssh-connection-timeout-when-connecting
- https://patrickmn.com/aside/how-to-keep-alive-ssh-sessions/
しかし、この問題を説明する投稿は見つかりませんでした。この動作について何かご存知の方はいらっしゃいますか? 4G ホットスポット接続の詳細を喜んでご提供いたします。
答え1
システムがステートフルに接続を追跡（および忘れる）していることが原因だと推測します。NAT が使用されている場合（IPv6 以外ではよくあることですが）、通常、NAT を実行するシステムは応答をどこに送り返すかを覚えておくためのメモリを必要とします。Wifi ブロードバンドの場合、NAT を実行するシステムはアクティブな接続を覚えておくためのメモリがより長い可能性があります（たとえば、Linuxネットフィルターの接続トラックデフォルトでは、TCP 接続は 5 日間記憶されますが、UDP フローは 2 ～ 3 分間記憶されます。4G パスで NAT を実行する同等のシステムのメモリはおそらく短く、3 分弱です。
これを回避するには、質問で見つけてリンクしたように、特定のsshパラメータを設定できます。ServerAliveInterval アクティビティがないときに定期的に空のデータ（SSHプロトコルとして）を送信する。TCP キープアライブこれにより、NAT を実行するシステムでは接続が常にアクティブとみなされ、システムはそれを忘れなくなります。そのため、ファイルに以下を~/.ssh/config追加できます。
ServerAliveInterval 115
115 は、保守的であるため 2 分よりわずかに短い値に選択されています。これは、パス内の非表示 NAT デバイス上のアクティブな接続の推定追跡期間よりも短い値ですが、低すぎるわけでもありません (後述)。そのため、最悪の場合、追跡状態が削除されるまであと 5 秒のときに、想定される 120 秒の寿命に戻ります。
欠点は、（Wifiブロードバンドアクセスの場合）接続がしばらく途切れて回復すると、クライアントがリモートサーバーがダウンしたと認識し、接続が切断される可能性があることです。ServerAliveCountMaxただし、デフォルト値が 3 の場合、この問題が発生するまでに、3*115=345 秒、つまり 5 分以上の接続損失が必要になります。
サーバー側には同等のClientAliveInterval同じ目的で、代わりにそのsshd_configファイルで設定できます。これにより、クライアント側が接続を失った場合に、ゴースト SSH クライアント接続が一定時間接続されていると見なされ続けることがなくなるという追加の利点があります。