DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ

SSHタイムアウト問題を防ぐためのベストプラクティス

クライアントキープアライブ、適切なサーバー設定、長時間の作業にはtmuxやscreenを使用して、アイドル状態のSSH切断を防ぎます。

SSHタイムアウト問題を防ぐためのベストプラクティス

SSHタイムアウトは、数分間アイドル状態が続いた後にターミナルがフリーズし、broken pipeやconnection resetエラーが表示されることで現れます。原因は多くの場合、ファイアウォール、NATゲートウェイ、VPN、ロードバランサーが、SSHクライアントが気づく前にアイドル状態のTCPセッションを切断することです。

最も有効な修正方法は、クライアントからのSSHキープアライブです。サーバー側の設定も役立ちますが、目的が異なり、設定を過剰にするとデッドクライアントを切断する可能性があります。

SSHタイムアウトの根本原因を理解する

SSHタイムアウトは、クライアントとサーバー間の通信リンクが、一定期間アクティビティが検出されなかったために切断されることで発生します。これは通常、SSHソフトウェア自体ではなく、リソースを節約するためにアイドル接続を積極的に削除する中間ネットワークデバイス（ファイアウォール、ルーター、NATテーブル）が原因です。

ファイアウォールが特定のTCP接続で数分間トラフィックを確認しないと、セッションがデッドと見なされ、接続状態が削除されます。次にSSHクライアントがデータを送信しようとすると、サーバーはそれを受信せず、セッションがフリーズし、最終的にタイムアウトエラーが発生します。

解決策は、SSHを構成して定期的にキープアライブ信号（小さな非データパケット）を送信し、中間デバイスが接続をアクティブと認識するようにすることです。

1. クライアント側の解決策: ServerAliveInterval

タイムアウトを防ぐための最も一般的で簡単な解決策は、SSHクライアントを構成して定期的にキープアライブメッセージをサーバーに送信することです。これはServerAliveIntervalディレクティブで制御されます。

ServerAliveIntervalの仕組み

ServerAliveIntervalは、サーバーからデータを受信していない場合に、クライアントがサーバーにnullパケットを送信するまでの秒数を指定します。この値により、クライアント側が接続状態を維持します。

~/.ssh/configによる設定

この方法は、グローバルまたはホストごとに設定でき、再起動や異なるターミナルセッション間で永続化できるため推奨されます。

クライアント設定ファイル（通常は~/.ssh/config）を作成または変更します：

nano ~/.ssh/config

設定をグローバル（すべてのホスト）に適用するには：

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3

値の説明：

  • ServerAliveInterval 60: 接続がアイドル状態の場合、クライアントは60秒ごとにキープアライブパケットを送信します。
  • ServerAliveCountMax 3: クライアントがサーバーから応答なしに3回連続でキープアライブメッセージを送信した場合、クライアントは接続を終了します。（合計タイムアウト時間：60秒 * 3回 = 180秒）。

コマンドラインによる設定

一時的な修正が必要な場合、または単一セッションにのみ設定を適用したい場合は、接続時に-oオプションを使用します：

ssh -o "ServerAliveInterval 60" user@remote_host

ヒント： 30〜60秒の値が通常理想的です。これはほとんどのファイアウォールルール（多くの場合約5分に設定）をバイパスするのに十分頻繁でありながら、過剰なネットワークオーバーヘッドを生成しない頻度です。

2. サーバー側の解決策: キープアライブの強制

クライアント側の解決策（ServerAliveInterval）で通常十分ですが、多くのユーザーがアクセスするサーバーを管理する管理者は、キープアライブ設定を中央で強制したり、アイドル接続に厳しい制限を設定したい場合があります。これはSSHデーモン設定ファイル/etc/ssh/sshd_configで行います。

ClientAliveIntervalとClientAliveCountMaxの使用

これらのディレクティブは、クライアント設定に対応するサーバー側のものです。サーバーにクライアントがまだ接続されているか確認するよう指示します。

  1. SSHデーモン設定ファイルを開きます：

    sudo nano /etc/ssh/sshd_config

  2. 次の行を追加または変更します：

    # サーバーはクライアントトラフィックがない場合、300秒後にクライアントアライブメッセージを送信します。
ClientAliveInterval 300

# 3回の未応答クライアントアライブメッセージ後に切断します。
ClientAliveCountMax 3

ClientAliveCountMaxに関する注意：

ClientAliveIntervalメッセージはSSHレベルのプローブであり、単なる「このアイドル時間後に切断」という設定ではありません。ClientAliveInterval 300とClientAliveCountMax 3の場合、サーバーは約15分間の未応答プローブ後にのみ切断します。OpenSSHでは、ClientAliveCountMax 0はこれらのサーバーキープアライブメッセージを無効にするため、タイムアウト強制の良い例ではありません。

  1. 変更を有効にするためにSSHサービスを再起動します：

    sudo systemctl reload sshd
# または
sudo service ssh reload

3. 高度な回復力戦略

SSHキープアライブは短い非アクティブ期間を処理しますが、完全なネットワーク中断（Wi-Fiネットワークの変更や一時的な信号喪失など）は依然としてTCP接続を切断します。真の回復力には、セッション管理ツールを使用します。

ターミナルマルチプレクサの活用（tmuxまたはscreen）

ターミナルマルチプレクサは、接続切断に対する究極の防御策です。これらはリモートサーバー上でセッションを実行し、クライアント接続が切断されても持続します。セッションからデタッチし、後で（同じまたは異なるクライアントから）再接続し、再アタッチして中断したところから正確に再開できます。

基本的なtmuxワークフロー：

  1. サーバーに接続します：
    ssh user@remote_host
  2. サーバー上で新しいtmuxセッションを開始します：
    tmux new -s my_session
  3. tmuxセッション内で作業します。
  4. 接続が切断された場合、または離れる必要がある場合、セッションをデタッチします（Ctrl+B、次にD）。
  5. SSH経由でサーバーに再接続します。
  6. 既存のセッションに再アタッチします：

tmux attach -t my_session ```

SSHキープアライブとTCPキープアライブの区別

基盤となるオペレーティングシステムのTCPキープアライブメカニズムを使用することも可能で、sshd_configのTCPKeepAlive yesディレクティブで設定されることがよくあります。ただし、SSHレベルのキープアライブ（ServerAliveInterval）が一般的に推奨されます。その理由は：

  1. 移植性： SSHディレクティブは、基盤となるOSカーネルのチューニングに関係なく一貫して動作します。
  2. アプリケーション層： SSHキープアライブはアプリケーション層内で動作し、SSHデーモンが応答性を維持することを保証します。
  3. ファイアウォール認識： TCPキープアライブは、ペイロードアクティビティのみをチェックするファイアウォールやNATデバイスによって静かにブロックされることがありますが、SSHキープアライブはこれらの層を正常に通過するように特別に設計されています。

TCPKeepAlive yesを使用する場合、実際の間隔タイミングはSSH設定ではなく、オペレーティングシステム（例：Linuxのnet.ipv4.tcp_keepalive_time）によって制御されることに注意してください。

ベストプラクティスのまとめ

問題 設定ディレクティブ 場所 推奨値 目的
クライアントタイムアウト ServerAliveInterval ~/.ssh/config（クライアント） 30〜60秒 クライアントからサーバーにnullパケットを送信し、ファイアウォールによる切断を防ぐ。
クライアント切断しきい値 ServerAliveCountMax ~/.ssh/config（クライアント） 3〜5 クライアントが切断するまでの応答欠落回数。
サーバーアイドル強制 ClientAliveInterval /etc/ssh/sshd_config（サーバー） 300秒（5分） サーバーからクライアントにチェックを送信し、アクティビティを監視する。
接続回復力 N/A サーバーセッション tmuxまたはscreen ネットワーク障害にもかかわらずセッションの永続性を可能にする。

クライアント設定でServerAliveIntervalから始めてください。長時間の移行、パッケージアップグレード、ログ調査の場合は、tmuxまたはscreen内で作業を実行し、ネットワークパスの切断がジョブを停止させないようにしてください。