SSH接続が切れやすいときに見直したい設定項目

SSH接続がすぐ切れると、作業効率が一気に落ちる

サーバー作業をしているときに、SSH接続が突然切れてしまうことがあります。

少しログを見ていただけなのに切れる。

長めのコマンドを実行していたら、いつの間にか反応しなくなる。

数分席を外して戻ってきたら、ターミナルが固まっている。

こういう状態になると、地味にストレスがたまります。

SSHはサーバー管理や開発作業ではよく使う基本的な接続方法です。Linuxサーバーにログインしたり、クラウド上の仮想マシンを操作したり、Gitサーバーと通信したりするときにも使われます。

本来、SSH接続は安定していてほしいものです。ただし、実際にはネットワーク環境、クライアント側の設定、サーバー側の設定、途中にあるルーターやファイアウォールなど、いろいろな要因で切れやすくなることがあります。

この記事では、SSH接続が切れやすいときに見直したい設定項目を、初心者の方にもわかりやすいように整理して紹介します。

「SSHの仕組みを細かく全部理解する」というよりも、まずは困ったときにどこを見ればよいかがわかることを目標にしていきます。

SSH接続が切れる主な原因

SSH接続が切れる原因はひとつとは限りません。よくある原因としては、次のようなものがあります。

一定時間操作がないことで、サーバーやネットワーク機器が接続を不要と判断して切ってしまうケース。

クライアント側やサーバー側で、接続維持のための通信が設定されていないケース。

Wi-FiやVPNなど、ネットワークそのものが不安定なケース。

ファイアウォールやロードバランサーが、無通信状態の接続をタイムアウトさせるケース。

サーバー側のSSH設定で、ログイン後のセッション維持に関する値が短く設定されているケース。

SSH接続は、見た目としては「ターミナルでサーバーに入っているだけ」に見えます。しかし実際には、クライアントPCとサーバーの間で通信が続いています。

イメージとしては、電話をつないだままにしている状態に近いです。会話していなくても電話回線はつながっています。ただ、長時間何も話さない状態が続くと、途中の機器が「もう使っていないのでは？」と判断して切ってしまうことがあります。

SSHでも同じように、しばらくキー入力や通信がないと、途中のネットワーク機器やサーバー側の設定によって切断されることがあります。

まず確認したいのは「どこで切れているか」

SSHが切れるとき、最初に考えたいのは「クライアント側の問題なのか」「サーバー側の問題なのか」「途中のネットワークの問題なのか」です。

とはいえ、最初から正確に切り分けるのは難しいです。そこで、まずは現象を観察します。

たとえば、次のような違いがあります。

何も操作しないで数分たつと毎回切れる場合は、タイムアウト系の設定が疑われます。

コマンド実行中にも切れる場合は、ネットワークの不安定さやサーバー負荷も考えられます。

特定の場所、たとえば自宅Wi-Fiからだけ切れる場合は、ローカルネットワークや回線側の影響がありそうです。

VPN接続中だけ切れる場合は、VPN側のタイムアウト設定が関係しているかもしれません。

まずは「何分くらいで切れるのか」「操作していても切れるのか」「特定の環境だけで起きるのか」を見るだけでも、原因の絞り込みがしやすくなります。

クライアント側の設定を見直す

SSH接続が切れやすいとき、最初に試しやすいのがクライアント側の設定です。

クライアント側とは、SSH接続を開始する自分のPCや作業端末のことです。MacやLinuxならsshコマンド、WindowsならPowerShell、Windows Terminal、またはSSHクライアントソフトを使っていることが多いと思います。

ServerAliveInterval

クライアント側で特によく使うのが、ServerAliveInterval です。

これは、SSHクライアントからサーバーに対して「まだ接続していますよ」という確認通信を送る間隔を指定する設定です。

たとえば、次のように指定できます。

ssh -o ServerAliveInterval=60 user@example.com

この例では、60秒ごとにサーバーへ確認通信を送ります。

何も操作していない状態でも、クライアントから定期的に小さな通信が送られるため、途中のネットワーク機器から「無通信」と判断されにくくなります。

毎回コマンドに指定するのが面倒な場合は、SSHの設定ファイルに書いておくと便利です。

Host *
    ServerAliveInterval 60

設定ファイルは、多くの環境では次の場所にあります。

~/.ssh/config

Host * は「すべてのSSH接続に適用する」という意味です。特定のサーバーだけに適用したい場合は、Host名を分けて設定できます。

Host myserver
    HostName example.com
    User user
    ServerAliveInterval 60

このようにしておくと、次回からは次のように短く接続できます。

ssh myserver

ServerAliveCountMax

ServerAliveInterval と一緒に見直したいのが、ServerAliveCountMax です。

これは、サーバーから応答がない状態を何回まで許容するかを指定する設定です。

たとえば、次のように設定します。

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3

この場合、60秒ごとに確認通信を送り、3回連続で応答がなければ接続を切ります。つまり、サーバーから約3分間応答がなければ切断されるイメージです。

この設定は「接続をなるべく維持する」ためだけでなく、「本当に通信できなくなったときに、いつまでも固まったままにしない」ためにも役立ちます。

SSHが固まっているのか、単にコマンドの処理が長いのか判断しにくいことがあります。ServerAliveCountMax を適切に設定しておくと、通信不能になった接続をある程度自動的に切り離せます。

サーバー側の設定を見直す

クライアント側の設定で改善しない場合は、サーバー側のSSH設定も確認します。

サーバー側のSSH設定ファイルは、多くのLinux環境では次の場所にあります。

/etc/ssh/sshd_config

このファイルを編集するには管理者権限が必要です。また、設定を間違えるとSSH接続できなくなる可能性もあります。作業する場合は、既存の接続を切らずに別ターミナルで確認するなど、慎重に進めるのがおすすめです。

ClientAliveInterval

サーバー側でよく使う設定が ClientAliveInterval です。

これは、SSHサーバーからクライアントに対して「まだ応答できますか？」という確認通信を送る間隔です。

たとえば、次のように設定します。

ClientAliveInterval 60

この設定を入れると、サーバーは60秒ごとにクライアントへ確認通信を送ります。

クライアント側の ServerAliveInterval と似ていますが、方向が逆です。

• ServerAliveInterval はクライアントからサーバーへの確認。
• ClientAliveInterval はサーバーからクライアントへの確認。

どちらも接続維持に関係しますが、設定する場所が違います。

ClientAliveCountMax

ClientAliveInterval と一緒に使うのが ClientAliveCountMax です。

ClientAliveInterval 60
ClientAliveCountMax 3

この場合、サーバーは60秒ごとに確認通信を送り、3回連続でクライアントから応答がなければ接続を切ります。

つまり、クライアントから約3分間応答がないと、サーバー側がセッションを終了します。

ここで注意したいのは、値をむやみに大きくしすぎないことです。

接続を長く維持したいからといって、極端に長い時間セッションを残す設定にすると、切断されたはずのセッションがサーバー側に残り続けることがあります。運用環境では、セキュリティやリソースの観点からも、適度な値にしておくのが大切です。

設定変更後はsshdを再起動する

sshd_config を変更しただけでは、設定はすぐに反映されません。SSHサーバーの再読み込み、または再起動が必要です。

一般的には次のようなコマンドを使います。

sudo systemctl reload sshd

環境によってはサービス名が ssh の場合もあります。

sudo systemctl reload ssh

いきなり restart すると、環境によっては既存接続に影響することがあります。まずは reload で反映できるか確認するのが無難です。

また、設定ファイルに文法ミスがあると、SSHサーバーが正常に起動できなくなる可能性があります。可能であれば、反映前に設定チェックを行います。

sudo sshd -t

何も表示されなければ、基本的には文法上の問題はないと考えられます。エラーが出た場合は、表示された行番号や設定項目を確認して修正します。

TCPKeepAliveも確認しておく

SSHには TCPKeepAlive という設定もあります。

これは、SSHそのものというより、TCPレベルで接続の生存確認を行う設定です。TCPは通信の土台になる仕組みで、SSHはその上で動いています。

たとえるなら、SSHが「会話の内容」だとすると、TCPは「電話回線そのもの」です。TCPKeepAlive は、その電話回線がまだ生きているかを確認するようなものです。

sshd_config では、次のように設定されていることがあります。

TCPKeepAlive yes

通常は yes で問題ありません。

ただし、TCPKeepAlive はOSやネットワーク環境の影響を受けやすく、確認間隔もSSHの ServerAliveInterval や ClientAliveInterval ほど細かく制御しやすいわけではありません。

そのため、SSH接続が切れやすい問題に対しては、まず ServerAliveInterval や ClientAliveInterval を見直すほうが実用的です。

NATやファイアウォールによるタイムアウト

SSH接続が切れる原因として、意外と多いのが途中のネットワーク機器によるタイムアウトです。

たとえば、自宅のルーター、会社のネットワーク機器、クラウド環境のファイアウォール、VPN機器などです。

これらの機器は、通信がしばらくない接続を自動的に破棄することがあります。理由は単純で、使われていない接続情報をいつまでも保持していると、機器のメモリや管理テーブルを消費するからです。

特にNAT環境では、この影響が出やすいです。

NATは、複数の端末がひとつのグローバルIPアドレスを共有するための仕組みです。家庭用ルーターや会社のネットワークでもよく使われています。NAT機器は「この内部端末の通信は、この外部通信に対応している」という情報を一定時間保持します。

しかし、無通信状態が続くと、その対応情報が消されることがあります。すると、SSHクライアント側ではまだ接続しているつもりでも、実際には途中の経路で通信が通らなくなってしまいます。

このようなケースでも、ServerAliveInterval を設定して定期的に通信を流すことで改善することがあります。

Host *
    ServerAliveInterval 30
    ServerAliveCountMax 5

30秒ごとに小さな通信を送ることで、NATやファイアウォールに「この接続はまだ使われている」と認識させるイメージです。

Wi-FiやVPNの不安定さも見落とさない

SSHの設定を見直しても改善しない場合、ネットワーク自体が不安定な可能性もあります。

特にWi-Fi接続では、電波状況やアクセスポイントとの距離、周囲の干渉によって通信が一瞬途切れることがあります。Webブラウジングでは気づきにくくても、SSHのような継続的な接続では影響が出ることがあります。

VPNを使っている場合も同様です。VPNは通信経路が通常より複雑になります。VPNサーバー、社内ネットワーク、クラウド環境など、経由する場所が増えるため、どこかでタイムアウトや瞬断が起きるとSSHにも影響します。

この場合は、次のような切り分けが役立ちます。

• 有線LANで接続すると安定するか。
• 別のWi-Fi環境ではどうか。
• VPNを使わない接続では切れないか。
• 特定のサーバーだけで発生するのか。
• 時間帯によって発生頻度が変わるか。

SSHの設定だけで解決できることもありますが、回線やVPNの問題が根本原因の場合は、ネットワーク側の調査も必要になります。

長時間作業にはtmuxやscreenを使う

SSH接続が切れやすい環境では、接続そのものを安定させる設定とあわせて、作業を失わない工夫も大切です。

代表的なのが tmux や screen です。

これらは、サーバー上でターミナルセッションを維持するためのツールです。SSH接続が切れても、サーバー上の作業セッション自体は残せます。

たとえば tmux を使うと、SSHでログインしたあとに次のようにセッションを開始できます。

tmux

その中で作業していれば、SSHが切れても再接続後にセッションへ戻れます。

tmux attach

これはかなり実務で役立ちます。

たとえば、長時間かかるログ調査、データ移行、ビルド処理、バックアップ作業などを行う場合、SSHが切れると作業内容が失われることがあります。tmux を使っていれば、接続が切れても作業を継続できるため、安心感が大きく変わります。

SSH接続の安定化はもちろん大事ですが、「切れたとしても困らない状態にする」ことも、実務ではかなり重要です。

nohupやバックグラウンド実行も検討する

長時間コマンドを実行する場合、tmux以外にも nohup やバックグラウンド実行を使う方法があります。

nohup ./long-task.sh > output.log 2>&1 &

このように実行すると、SSH接続が切れてもコマンドが継続しやすくなります。

ただし、初心者の方には tmux のほうが扱いやすいことが多いです。なぜなら、tmux はあとから作業画面に戻れるため、何が起きているか確認しやすいからです。

nohup は「処理を裏で流してログを見る」ような使い方に向いています。

tmux は「作業中のターミナル画面ごと残しておく」使い方に向いています。

実務では、サーバーに入ったらまず tmux を起動する、という運用にしている現場もあります。それくらい、長時間作業では便利です。

SSHクライアントソフト側の設定も確認する

Windows環境などでGUIのSSHクライアントソフトを使っている場合は、そのソフト独自の接続維持設定も確認してみましょう。

たとえば、「keep alive」「heartbeat」「null packet」「anti-idle」のような名前で設定が用意されていることがあります。

意味としては、一定間隔でサーバーへ小さな通信を送る設定です。OpenSSHの ServerAliveInterval と近い役割です。

ソフトによって名前や設定画面は違いますが、「SSH 接続維持」「KeepAlive」「タイムアウト」あたりの項目を探すと見つかることが多いです。

ここで注意したいのは、クライアントソフト側とSSH設定ファイル側で、似たような設定が重複することです。

重複していても大きな問題にならないことは多いですが、原因調査中は「どこで何を設定しているか」を整理しておくと混乱しにくくなります。

サーバーのログを確認する

SSH接続が切れる原因を調べるには、サーバー側のログも有効です。

Linux環境では、SSH関連のログが次のような場所に出ることがあります。

/var/log/auth.log

または

/var/log/secure

systemd環境では、journalctl で確認することもあります。

sudo journalctl -u sshd

サービス名が ssh の場合は次のようにします。

sudo journalctl -u ssh

ログを見ると、認証失敗、接続終了、タイムアウト、設定エラーなどの手がかりが見つかることがあります。

ただし、SSHが切れた理由が必ずログに明確に出るとは限りません。特に、途中のネットワーク機器が接続を破棄した場合、サーバー側から見ると「クライアントがいなくなった」ようにしか見えないことがあります。

ログは万能ではありませんが、サーバー側で何か起きていないかを確認する材料になります。

実務でおすすめの設定例

実務でよく使いやすいクライアント側設定の例は、次のような形です。

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3

この設定は、まず試しやすいバランスです。60秒ごとに接続確認を行い、3回応答がなければ切断します。

ネットワーク機器のタイムアウトが短い環境では、次のように少し短めにすることもあります。

Host *
    ServerAliveInterval 30
    ServerAliveCountMax 5

ただし、むやみに短くしすぎる必要はありません。大量のSSH接続を同時に張る環境では、確認通信も積み重なると無視できない量になることがあります。

個人の開発作業や少数のサーバー管理であれば大きな問題になることは少ないですが、業務環境では「適度な間隔」にする意識が大切です。

サーバー側では、運用ポリシーに合わせて次のような設定を検討します。

ClientAliveInterval 60
ClientAliveCountMax 3

ただし、サーバー側設定は全ユーザーに影響することがあります。個人の都合だけで変更するのではなく、チームや管理方針に合わせて決めるのが安全です。

セキュリティ面で気をつけたいこと

SSH接続を長く維持できるようにすることは便利ですが、セキュリティ面も忘れてはいけません。

たとえば、離席中にSSHセッションが残り続けると、第三者がその端末を操作できてしまうリスクがあります。特に共有PCやオフィス環境では注意が必要です。

接続を切れにくくする設定と、セッションを残しっぱなしにしない運用はセットで考えるべきです。

実務では、次のような考え方が現実的です。

• 作業端末には画面ロックを設定する。
• 使い終わったSSHセッションは明示的にログアウトする。
• 長時間処理は tmux などで管理し、不要になったセッションは終了する。
• サーバー側のタイムアウト設定を無制限にしない。
• 踏み台サーバーなど重要な環境では、組織のセキュリティ方針を優先する。

便利さだけを優先して「絶対に切れないSSH」を目指すと、かえって危険な運用になることがあります。

SSH接続は、必要な間は安定して使える。不要になったらきちんと閉じる。

このバランスが大事です。

実務での切り分け手順

SSH接続が切れやすいと相談されたときは、次のような順番で見ると整理しやすいです。

まず、何分くらいで切れるかを確認します。毎回同じくらいの時間で切れるなら、タイムアウト設定がかなり怪しいです。

次に、クライアント側の ServerAliveInterval を設定します。これは自分の環境だけで試せるため、影響範囲が小さく、最初の対策として向いています。

それでも改善しない場合は、接続元のネットワークを変えてみます。Wi-Fiから有線LANに変える、VPNを外して確認する、別の回線から試す、といった切り分けです。

さらに、サーバー側の sshd_config を確認します。ClientAliveInterval や ClientAliveCountMax がどう設定されているか、極端な値になっていないかを見ます。

最後に、ファイアウォール、ロードバランサー、NAT、VPN機器など、途中経路のタイムアウト設定を確認します。クラウド環境では、セキュリティグループだけでなく、踏み台サーバーやプロキシ構成も関係することがあります。

大切なのは、いきなり全部を変えないことです。

一度に複数の設定を変更すると、何が効いたのかわからなくなります。まずクライアント側、次にネットワーク、次にサーバー側、というように順番に見ていくと、原因を追いやすくなります。

よくある疑問

ServerAliveInterval と ClientAliveInterval は両方必要ですか？

必ず両方必要というわけではありません。

まずはクライアント側の ServerAliveInterval から試すのがおすすめです。自分の端末だけで設定でき、サーバー全体への影響が少ないためです。

サーバー全体として一定のポリシーで接続管理したい場合は、ClientAliveInterval も検討します。

値は何秒くらいがよいですか？

よく使いやすいのは30秒から60秒程度です。

まずは60秒で試して、まだ切れる場合は30秒にする、という進め方がわかりやすいです。極端に短い値にすると不要な通信が増えるため、必要以上に短くする必要はありません。

SSHが固まったときに抜ける方法はありますか？

SSHセッションが反応しなくなった場合、エスケープシーケンスで切断できることがあります。

改行したあとに、次のキーを入力します。

~.

チルダに続けてドットです。画面には表示されないこともありますが、SSHクライアントが反応すれば接続を終了できます。

長時間処理はどう実行するのが安全ですか？

tmux を使うのがおすすめです。

SSHが切れても作業セッションを残せるため、長時間のログ確認、ビルド、データ処理などで安心です。サーバー作業に慣れてきたら、早めに覚えておくとかなり役立ちます。

まとめ

SSH接続が切れやすいときは、まず「無通信によるタイムアウト」を疑うと整理しやすいです。

最初に見直したいのは、クライアント側の ServerAliveInterval と ServerAliveCountMax です。自分の端末だけで設定できるため、試しやすく、効果も出やすい設定です。

サーバー側では、ClientAliveInterval と ClientAliveCountMax を確認します。ただし、サーバー側の設定は他のユーザーにも影響するため、運用方針に合わせて慎重に変更する必要があります。

また、SSHの設定だけでなく、Wi-Fi、VPN、NAT、ファイアウォール、ロードバランサーなど、途中のネットワーク機器が原因になることもあります。特に「一定時間操作しないと切れる」場合は、どこかでタイムアウトが発生している可能性が高いです。

そして実務では、接続を切れにくくするだけでなく、切れても困らない準備も大切です。tmux や screen を使えば、SSHが切れても作業状態をサーバー側に残せます。

SSH接続の安定化は、派手な技術ではありませんが、日々のサーバー作業をかなり快適にしてくれます。まずは ~/.ssh/config に ServerAliveInterval を設定するところから始めると、効果を実感しやすいはずです。