DevOpsナレッジハブ
DevOpsナレッジハブ

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

堅牢なキープアライブ設定を導入して、イライラするSSHセッションの切断を防ぎましょう。この必携ガイドでは、クライアント側 (`ServerAliveInterval`) とサーバー側 (`ClientAliveInterval`) の設定の違いを詳しく解説し、`~/.ssh/config` ファイルを調整するための段階的な手順を提供します。積極的なファイアウォールやNATのタイムアウトを回避するための実用的な値の使い方を学び、不安定なネットワーク上でも安定した永続的な接続性を確保します。また、究極のセッション回復力のために `tmux` のようなマルチプレクサを活用するための推奨事項も含まれています。

34 ビュー

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

SSH (Secure Shell) は、暗号化された安全な接続性を提供するリモートシステム管理の基盤です。しかし、タイムアウトによりセッションが予期せず切断されるほど苛立たしいことはほとんどありません。これらの問題は、不安定なネットワーク、積極的なNATデバイスを介した接続、またはセッションが一定期間アイドル状態にある場合に特に顕著です。

このガイドでは、システム管理者と開発者が安定したSSHセッションを積極的に維持するために実装できる、クライアント側とサーバー側の両方における重要な設定調整について解説します。組み込みのキープアライブメカニズムを活用することで、ネットワークの不安定な期間や非アクティブ期間中であっても、重要なタスクが中断されないようにすることができます。

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

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

ファイアウォールが特定のTCP接続で数分間トラフィックを検出しなかった場合、そのセッションは終了したとみなし、接続状態を破棄します。次にSSHクライアントがデータを送信しようとしても、サーバーはそれを受け取らず、セッションのフリーズと最終的なタイムアウトエラーにつながります。

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

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

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

ServerAliveIntervalの仕組み

ServerAliveIntervalは、サーバーからデータが受信されなかった場合に、クライアントがサーバーにヌルパケットを送信するまでの時間を秒単位で指定します。この値により、クライアント側が接続状態を維持します。

~/.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デーモンの設定ファイルを開きます。

    bash sudo nano /etc/ssh/sshd_config

  2. 以下の行を追加または変更します。

    ```config

    クライアントから300秒間（5分間）データが受信されない場合、サーバーはヌルパケットを送信します

    ClientAliveInterval 300

    ClientAliveIntervalが0回応答なしでトリガーされた場合、切断します。

    この値を0に設定すると、サーバーは最初のチェックが失敗した直後に切断します。

    ClientAliveCountMax 0
    ```

ClientAliveCountMaxに関する注意：

ClientAliveCountMaxを低い値（0や1など）に設定すると、サーバーは厳密なアイドルタイムアウトを強制します。たとえば、ClientAliveInterval 300とClientAliveCountMax 0は、ユーザーが5分間完全にアイドル状態である場合、サーバーは接続が終了したとみなし、切断を強制することを意味します。これはセキュリティには役立ちますが、ユーザーにとっては苛立たしいものとなる可能性があります。ファイアウォールによる接続切断を防ぐことが目標であれば、ここで値を設定することは、クライアント側のServerAliveIntervalよりも優先順位が低いことがよくあります。

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

    ```bash
    sudo systemctl restart sshd

    または

    sudo service sshd restart
    ```

3. 高度な回復戦略

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

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

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

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

  1. サーバーに接続します。
    bash ssh user@remote_host
  2. サーバーで新しいtmuxセッションを開始します。
    bash tmux new -s my_session
  3. tmuxセッション内で作業します。
  4. 接続が切断された場合、または作業を中断する必要がある場合は、セッションをデタッチします（Ctrl+Bを押してからDを押します）。
  5. SSH経由でサーバーに再接続します。
  6. 既存のセッションに再アタッチします。
    bash 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を使用することを選択した場合、実際のインターバルタイミングは（例えばLinuxのnet.ipv4.tcp_keepalive_timeのような）オペレーティングシステムによって制御され、SSH設定によるものではないことを忘れないでください。

ベストプラクティスの概要

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

クライアントマシンにServerAliveIntervalディレクティブを実装することで、ネットワークの非アクティブによって引き起こされるSSHタイムアウト問題の大部分に対処できます。ミッションクリティカルなタスクの場合、この設定をセッションマルチプレクサと組み合わせることで、接続中断に対するほぼ完全な耐性が得られます。