WordPress 保守業務で複数サイトを Xserver に持っているエージェンシーなら、ほぼ確実に一度は遭遇する症状があります。「今朝まで普通に繋がっていた Xserver の SSH に、急に繋がらなくなった」。鍵を変えた覚えはない、サーバー側で何かが起きたわけでもない。それでも Connection closed by ... で即切られて、再試行を重ねるほど沈黙が深くなる。
この症状の正体について、先日 Xserver サポートから公式回答を得る機会があったので、運用者として知っておきたい範囲で整理しておきます。
症状の典型像
弊社が観測した範囲では、症状は次の 2 段階で進みます。
- 軽め:
Connection closed by [Xserver の IP]（接続が確立せずに sshd レベルで切られる） - 重め:
ssh: connect to host ... port 10022: Connection refused（firewall reject まで上がる）
軽めの段階で気付ければまだ復旧が見通せますが、再試行を繰り返すと重い方に進みます。待つ以外の選択肢が一時的に消えるのはこの段階です。
Xserver サポートからの公式回答
別件で Xserver サポートにエスカレーションした際に、「SSH 接続元 IP が一時的に弾かれる挙動」について次の公式回答を受け取りました。
試行回数の上限に達した場合、fail2ban により接続元 IP を一時的に接続制限する仕組みになっております。試行回数の閾値・bantime・findtime・手動解除可否などの具体的な仕組みは、セキュリティ上非公開とさせていただいております。
つまり Xserver 側の Connection closed / Connection refused は仕様としての保護機構で、サーバー側に異常が起きているわけではない、ということです。閾値が非公開なのは攻撃側に逆用される情報なので妥当ですが、運用上は次の 2 点が分かっていれば回せます。
- 手動解除のサポート窓口は存在しない（自分で待つしかない）
- 半日〜1 日程度の経過で自然解除される（弊社実機検証で確認）
何が引き起こすか
SSH ブルートフォースを試みた覚えがない通常運用でも、構造的に発動する条件がいくつかあります。最頻出は 複数の SSH 鍵をエージェントに登録した状態で、Xserver に向けて自動接続を繰り返すケースです。
paramiko や ssh クライアントは、ホスト鍵 / ~/.ssh/id_* / SSH エージェント内の鍵を順に試行します。鍵を 3 個も登録していれば、1 回の接続で 3 〜 4 回の認証試行になり、これを保守ツールが複数サイトに対して並列に投げると、MaxAuthTries 超過の累積で fail2ban の発動条件に到達します。
このアプリ設計側の根本対策（look_for_keys=False / allow_agent=False で鍵試行を限定する）については paramiko の既定値が IP ブロックを誘発する話 に書きました。本稿は 既に繋がらなくなった後にどう動くか に絞ります。
既に繋がらなくなった時の動き方
選択肢は実質 2 つです。
1. 待つ — 解除を申請する窓口はないので、半日〜1 日待つのが最終的に最も短い経路です。重要度の高いメンテナンス予定がある場合は、クライアントに「サーバー側の保護機構による一時的な接続制限のため、解除後に再開します」と伝えるのが筋。「障害」と伝えると的を外します。
2. 接続元 IP を変える — 別回線（モバイル WiFi・ハンドセットテザリング・固定 IP サービス）から接続できれば即時復旧します。弊社の場合は国内固定 IP サービス（インターリンク マイ IP）を用意してあり、本回線がブロックされた状態でも固定 IP 経由で ssh layer2024@layer2024.xsrv.jp できることを実機で確認しています。fail2ban は IP 単位で動くので、別 IP からは普通に通ります。
再発を最小化する疎通確認コマンド
復旧後、最初に試すべきは「最小試行で繋がるか」を確認するコマンドです。鍵をいくつも登録している環境では、何も考えずに ssh user@host すると、また連鎖試行で同じブロックを踏みかねません。
ssh -i ~/.ssh/layer2024_xserver.key \
-o IdentitiesOnly=yes \
-o IdentityAgent=none \
-p 10022 \
layer2024@layer2024.xsrv.jp 'echo ok'
IdentitiesOnly=yes— 指定した-iの鍵だけを試す（~/.ssh/id_*の自動試行を止める）IdentityAgent=none— SSH エージェント内の鍵を一切試さない'echo ok'— シェルを開かず疎通だけ確認して即切断
このセットを「Xserver に触る時の標準疎通確認」として運用に組み込んでおくと、復旧後の確認が再ブロックの引き金になる事故を抑えられます。保守ツール側でも同じ設定（paramiko なら look_for_keys=False / allow_agent=False）を入れていれば、構造的に再発しなくなります。
まとめ
Xserver の SSH が突然繋がらなくなったら、まず「サーバー異常ではなく fail2ban の発動」を疑ってください。手動解除の経路はないので、待つか、別 IP に切り替えるかの 2 択。復旧後の最初の接続は IdentitiesOnly=yes / IdentityAgent=none で最小試行に絞る。アプリ側の根本対策が必要であれば paramiko 既定値の落とし穴 を併せて読むと、設計と運用の両面から手が打てます。
「サーバーが壊れたのではないか」と一拍焦るタイミングで、保護機構の発動だと言い切れるかどうかは、エージェンシー業務の落ち着き方を一段押し上げます。