この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
Linuxサーバーのファイアウォール設定を変更した直後に、このパターンに陥る人は少なくありません。私のセミナーでも「やってしまいました」という受講生の声を、これまで何十回と聞いてきました。
この記事では、私がSE時代（2001年～2005年）に実際にiptablesの設定ミスでSSH接続を失った体験と、そこから学んで20年以上ずっと守り続けている3つの鉄則をお伝えします。コンソールにたどり着けなかった場合の緊急対処法も含めて、教科書には載っていない現場の知識をまとめました。
この記事のポイント
・sshd_config変更後は sshd -t で構文テストをしてから再起動する
・SSH設定変更時は別セッションを維持したまま作業するのが鉄則
・iptablesのルールは「追加→確認→確定」の順番を必ず守る
・本番作業前にコンソール（帯域外）アクセスを必ず確認しておく
・コンソールが使えない場合はatコマンドで自動ロールバックを準備しておく
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
あの夜のこと——iptables設定後に固まった画面
SE時代、私は常駐先でLinuxサーバーのファイアウォール設定変更を任されていました。当時はiptablesが標準的なパケットフィルタリングツールで、設定ファイルを書き換えるより、コマンドでルールを一から組み直す方が確実だという考え方でした。作業の流れはこうです。
・まず
iptables -F（フラッシュ）で既存のルールをすべて削除する・新しいルールを順番にコマンドで追加していく
・最後に
/sbin/service iptables save でルールを永続化する手順通りに作業を進めて、最後のEnterキーを押した瞬間でした。SSHのセッションが突然固まりました。
「あれ？」と思いながら
Ctrl+C を試しても反応なし。別のターミナルウィンドウを開いてSSH接続を試みると、接続が拒否されます。——やってしまった、と分かった瞬間の感覚は今でも覚えています。
iptables -F で何が起きたのか
当時の私は「手順通りにやった」という意識があったため、なぜSSHが切れたのかが最初は分かりませんでした。後で整理してみると、次の3ステップで詰まっていました。1.
iptables -F（全ルール削除）を実行した2. デフォルトポリシーを
INPUT -j DROP（全パケット破棄）に変更した3. HTTPとHTTPSの許可ルールは追加したが、SSH（ポート22）の許可を書き忘れた
iptablesは「マッチするルールがなければデフォルトポリシーに従う」という仕組みです。ポリシーがACCEPTの状態でルールをフラッシュしても通信は通ります。しかしポリシーをDROPに変えた直後からは、明示的にACCEPTしていないすべての通信——SSHを含む——がサーバー側で静かに捨てられます。「接続できなくなった」ではなく「パケットが黙って廃棄されている」状態です。この挙動を知っていれば、事前に気づけました。
なお、これと構造的に似たパターンとして「sshd_configでSSHのポート番号を22番から別の番号に変えたのに、iptablesの許可ルールを旧ポートのまま放置して接続できなくなる」というケースも現場でよく起きます。私自身も同じSE時代の2004年頃に、客先でSSHのポート変更を行った直後にこのパターンを経験しました。sshd_configとファイアウォール——どちらか一方だけ変えても意味がなく、必ず両方をセットで更新する必要があります。
焦りの中で原因を探った
1. まず状況を整理した
焦っている時こそ、闇雲に動いてはいけません。私が最初にやったのは、「何の作業の直後にこうなったか」を手元のメモに書き出すことでした。・
iptables -F で既存ルールをすべて削除した・HTTPとHTTPSの許可ルールを追加した
・デフォルトポリシーを
DROP に変更した・ルールを保存した
書き出した時点で気づきました。「SSH（ポート22）の許可ルールを追加していない」——これが原因だと。iptables -Fですべてのルールを消した後、デフォルトポリシーをDROPにしたため、SSH通信がすべて遮断されてしまったのです。
2. コンソールでサーバーを直接確認した
当時の現場にはサーバールームがあり、KVMスイッチを経由してサーバーに物理コンソールで接続できました。ネットワーク経由のSSHが繋がらなくても、物理コンソールがあればサーバーには入れます。コンソールからroot権限でログインし、iptablesのルールを確認しました。
# iptables -L -n Chain INPUT (policy DROP) target prot opt source destination ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 # ポート22（SSH）の許可ルールが存在しない
3. ルールを追加して問題を解決した
コンソールから以下のコマンドを実行し、SSH許可ルールを先頭に追加しました。# SSH（ポート22）を許可するルールを先頭に追加 iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT # ルールを確認 iptables -L -n # ルールを永続化 /sbin/service iptables save
原因はシンプルでした。iptablesのルールを一から組み直す際に、SSH許可のルールを追加するつもりが、実際には書いていなかった。「書いたつもり」が「書いていなかった」——これが現場のミスの典型的な姿です。
コンソールが使えない場合の緊急対処法
上記の話では物理コンソールで助かりましたが、クラウドやVPS環境ではそもそも「サーバールームに行く」という選択肢がありません。SSHロックアウトが起きた時のために、環境別の対処手順を整理しておきましょう。1. クラウド・VPS環境の帯域外コンソールを使う
クラウドやVPS各社は、ネットワーク設定が壊れても管理画面からサーバーに接続できる手段を提供しています。・AWS EC2：マネジメントコンソールから「EC2 Instance Connect」またはSystems Manager Session Managerで接続できる（セキュリティグループの設定に影響されない）
・さくらのVPS：コントロールパネルの「VNCコンソール」でブラウザから直接接続できる
・ConoHa VPS：コントロールパネルの「コンソール」ボタンで同様にアクセス可能
・IPMI（物理サーバー）：BMC（Baseboard Management Controller）経由でネットワークOSとは独立したコンソールに接続できる
注意：これらのコンソールは事前に動作確認しておかないと、いざという時に「コンソールが有効化されていなかった」という事態になります。本番作業前に一度試しておくことが鉄則です。
2. iptablesルールを作業前にバックアップしておく
iptablesの設定を変更する前に、現在のルールをファイルに保存しておくと、失敗した時でもすぐに元に戻せます。# 作業前に現在のルールを保存する（日付付きファイル名推奨） iptables-save > /root/iptables_backup_$(date +%Y%m%d_%H%M%S).rules # 保存できたか確認する ls -la /root/iptables_backup_*.rules # 復元が必要になった時 iptables-restore < /root/iptables_backup_20260718_143000.rules
3. atコマンドで自動ロールバックを仕込む（上級者向け）
iptablesの設定を大きく変える時に使える上級テクニックとして、atコマンドによる自動ロールバックがあります。「5分後に元のルールに戻す」というコマンドを先に仕込んでおくことで、SSHが繋がらなくなっても時間が経てば自動的に復旧します。# 1. 現在のルールをバックアップ iptables-save > /root/iptables_rollback.rules # 2. 5分後に自動で元のルールを復元するジョブを登録する echo "iptables-restore < /root/iptables_rollback.rules" | at now + 5 minutes # 3. iptablesのルールを変更する（この間にSSHが切れても5分で自動復旧） iptables -F # ... 新しいルールを適用 ... # 4. SSHで問題なく接続できることを確認してから、atジョブをキャンセルする atq atrm <ジョブ番号>
atrm でジョブをキャンセルして変更を確定。問題が起きても5分待てば自動復旧します。クラウド環境でコンソールアクセスが不安な時に特に有効な手法です。ロックアウトから学んだ3つの鉄則
セミナーで3,100名以上を指導してきた中で、このSSHロックアウト体験の話をすると、必ず「自分も同じことをやりました」という声が上がります。そしてこの失敗から学ぶものは大きい。1. SSH設定変更時は別セッションを必ず維持する
ファイアウォールやSSHデーモン（sshd）の設定を変更するときは、必ず2つのSSHセッションを開いたまま作業します。・セッション1：設定変更作業用
・セッション2：接続確認用（常に開いたまま閉じない）
設定変更後にSSHが繋がらなくなっても、維持していたセッション2から修正できます。この手順は絶対に省略しません。「どうせすぐ終わるから」と一つのセッションだけで作業するのが、ロックアウトの入口です。
なお、セッションを維持しただけでは不十分な場面もあります。iptablesのルールを変更した直後に、維持しているセッション2から実際に再接続テストを行うこと——これが確認の実態です。維持していても「まあ大丈夫だろう」と確認を省くのは、やらないのと同じです。
加えて、sshd_configを編集する場合はsshdを再起動する前に必ず
sshd -t コマンドで構文テストを実施してください。設定ファイルの書き方にミスがあれば、この時点でエラーが表示されます。構文エラーがある状態でsshdを再起動するとsshdが起動できず、接続が完全に失われます。# sshd_configの構文テスト（再起動前に必ず実施する） sshd -t # 何も表示されなければ構文エラーなし（正常） # エラーがある場合は行番号とエラー内容が表示される # 例: /etc/ssh/sshd_config: line 15: Bad configuration option: Potrt
sshd -t はsshd_configの構文チェックのみです。「ファイアウォールが通信を許可しているか」は確認しません。sshd_configとファイアウォールは独立した2つの設定であることを、常に意識しておいてください。2. ルールは「試してから確定」の順番を守る
今はfirewalldを使う現場が多いですが、この原則は変わりません。設定変更はまずランタイム（一時）適用で試してから、永続化するのが基本です。# firewalldの場合: まずランタイムに追加して確認する firewall-cmd --add-service=ssh # 別のセッションからSSH接続を確認する # 問題がなければランタイム設定を永続化する firewall-cmd --runtime-to-permanent
同じ「試してから確定」の考え方は、sshdのリロードにも当てはまります。sshd_configを変更してsshdを再起動する際は、
systemctl restart sshd ではなく systemctl reload sshd を使うのが安全です。restartはsshdプロセスを一から立ち上げ直すため、作業中に開いていた「逃げ道」セッションも切れてしまいます。reloadは設定の再読み込みのみで、既存のSSHセッションは維持されます。詳しいfirewall-cmdの使い方は「firewall-cmdコマンドでポートを開放・管理する方法｜ゾーン・サービス・永続化の使い分け」も参考にしてください。
3. 本番サーバー作業前にコンソール接続を確認しておく
「ネットワーク越しのSSH」だけに頼って作業するのは危険です。本番サーバーの作業前には、ネットワーク設定が壊れても入れる手段を事前に確認しておきます。・データセンターのサーバー：物理コンソールやIPMI（BMC）アクセスを事前に確認する
・クラウド（AWS・Azure）：EC2 Instance ConnectやAzure Bastionの動作確認をしておく
・VPS：コントロールパネルのVNCコンソールを事前に試しておく
「SSHが繋がらなくなってもこれで入れる」という手段を持って作業することが、安心感につながります。コンソールは「保険」ではなく「作業の前提条件」として位置づけるのが現場の常識です。
3つの鉄則をまとめると、SSH設定変更の作業フローはこのようになります。
| 作業タイミング | やること |
|---|---|
| 変更前 | 帯域外コンソールの動作確認。sshd_config変更なら sshd -t で構文テスト。逃げ道セッションをもう1本開いておく |
| 変更中 | iptables/firewalldのルールはランタイム適用で試してから確定。sshdの再読み込みは reload を使う |
| 変更後 | 新設定での接続成功を確認してから旧ルールを削除。最後に逃げ道セッションを閉じる |
まとめ
「SSHが繋がらなくなった」という体験は、Linuxサーバー管理者の現場感覚を育てる大切な出来事です。20年以上の運用経験から言うと、この経験をした人ほど、その後の確認習慣が丁寧になります。| 鉄則 | 内容 |
|---|---|
| 構文テスト | sshd_config変更後は sshd -t で構文テストをしてから再起動する |
| セッションの保持 | SSH設定変更時は別セッションを維持したまま作業する |
| 確認してから確定 | ルールはランタイム適用で試してから永続化する。sshdはrestartではなくreloadで再読み込みする |
| 帯域外アクセス確保 | コンソール接続手段を本番作業前に必ず確認する |
| 事前バックアップ | iptables-save で変更前のルールを保存しておく |
SSH接続ミスを防ぐ「型」を、現場の手順として身につけませんか？
ロックアウトは、知識不足より「手順の省略」と「確認の省略」が原因です。まずは体系的にまとめられた教材で、サーバー構築の全体像を掴んでください。
ネットの切れ端の情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます