この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
Linuxサーバーのファイアウォール設定を変更した直後に、このパターンに陥る人は少なくありません。私のセミナーでも「やってしまいました」という受講生の声を、これまで何十回と聞いてきました。
この記事では、私がSE時代（2001年～2005年）に実際にiptablesの設定ミスでSSH接続を失った体験と、そこから学んで20年以上ずっと守り続けている3つの鉄則をお伝えします。教科書には載っていない現場の知識です。
この記事のポイント
・SSH設定変更時は別セッションを維持したまま作業するのが鉄則
・iptablesのルールは「追加→確認→確定」の順番を必ず守る
・本番作業前にコンソール（帯域外）アクセスを必ず確認しておく
・ロックアウト体験が、その後の確認習慣を作る出発点になる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
あの夜のこと——iptables設定後に固まった画面
SE時代、私は常駐先でLinuxサーバーのファイアウォール設定変更を任されていました。当時はiptablesが標準的なパケットフィルタリングツールで、設定ファイルを書き換えるより、コマンドでルールを一から組み直す方が確実だという考え方でした。作業の流れはこうです。
・まず
iptables -F（フラッシュ）で既存のルールをすべて削除する・新しいルールを順番にコマンドで追加していく
・最後に
/sbin/service iptables save でルールを永続化する手順通りに作業を進めて、最後のEnterキーを押した瞬間でした。SSHのセッションが突然固まりました。
「あれ？」と思いながら
Ctrl+C を試しても反応なし。別のターミナルウィンドウを開いてSSH接続を試みると、接続が拒否されます。——やってしまった、と分かった瞬間の感覚は今でも覚えています。
焦りの中で原因を探った
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許可のルールを追加するつもりが、実際には書いていなかった。「書いたつもり」が「書いていなかった」——これが現場のミスの典型的な姿です。
ロックアウトから学んだ3つの鉄則
セミナーで3,100名以上を指導してきた中で、このSSHロックアウト体験の話をすると、必ず「自分も同じことをやりました」という声が上がります。そしてこの失敗から学ぶものは大きい。1. SSH設定変更時は別セッションを必ず維持する
ファイアウォールやSSHデーモン（sshd）の設定を変更するときは、必ず2つのSSHセッションを開いたまま作業します。・セッション1：設定変更作業用
・セッション2：接続確認用（常に開いたまま閉じない）
設定変更後にSSHが繋がらなくなっても、維持していたセッション2から修正できます。この手順は絶対に省略しません。「どうせすぐ終わるから」と一つのセッションだけで作業するのが、ロックアウトの入口です。
2. ルールは「試してから確定」の順番を守る
今はfirewalldを使う現場が多いですが、この原則は変わりません。設定変更はまずランタイム（一時）適用で試してから、永続化するのが基本です。# firewalldの場合: まずランタイムに追加して確認する firewall-cmd --add-service=ssh # 別のセッションからSSH接続を確認する # 問題がなければランタイム設定を永続化する firewall-cmd --runtime-to-permanent
詳しいfirewall-cmdの使い方は「firewall-cmdコマンドでポートを開放・管理する方法｜ゾーン・サービス・永続化の使い分け」も参考にしてください。
3. 本番サーバー作業前にコンソール接続を確認しておく
「ネットワーク越しのSSH」だけに頼って作業するのは危険です。本番サーバーの作業前には、ネットワーク設定が壊れても入れる手段を事前に確認しておきます。・データセンターのサーバー：物理コンソールやIPMI（BMC）アクセスを事前に確認する
・クラウド（AWS・Azure）：EC2 Instance ConnectやAzure Bastionの動作確認をしておく
・VPS：コントロールパネルのVNCコンソールを事前に試しておく
「SSHが繋がらなくなってもこれで入れる」という手段を持って作業することが、安心感につながります。
SSH接続の基本から確認したい方は「LinuxへのSSH接続入門｜初心者でも安全にリモートサーバーにつなぐ方法」もあわせてご覧ください。
まとめ
「SSHが繋がらなくなった」という体験は、Linuxサーバー管理者の現場感覚を育てる大切な出来事です。20年以上の運用経験から言うと、この経験をした人ほど、その後の確認習慣が丁寧になります。| 鉄則 | 内容 |
|---|---|
| セッションの保持 | SSH設定変更時は別セッションを維持したまま作業する |
| 確認してから確定 | ルールはランタイム適用で試してから永続化する |
| 帯域外アクセス確保 | コンソール接続手段を本番作業前に必ず確認する |
SSH接続ミスを防ぐ「型」を、現場の手順として身につけませんか？
ロックアウトは、知識不足より「手順の省略」と「確認の省略」が原因です。まずは体系的にまとめられた教材で、サーバー構築の全体像を掴んでください。
ネットの切れ端の情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：Linuxでrm -rfを打つ前に手が止まった日の話｜現役講師が語る削除コマンドへの恐怖と20年間変えていない確認の習慣
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます