ufw でSSHが繋がらない時：許可ルールの確認と戻し方

2025-12-16 読了時間: 約12分 難易度: 中級

この記事で解決できること

• ufw が原因で SSH が繋がらない状況を、順番に切り分けできます
• 「許可したのに繋がらない」「急に繋がらなくなった」を、最短で復旧できます
• ありがちな事故（自分で自分を締め出す）を避ける"安全な進め方"が分かります

1. まず状況を整理（ここを飛ばすと迷子になります）

結論: 接続先ホスト・接続ポート・接続元の3点を最初に確定しないと原因調査で迷子になるため必ず先に整理する。

あなたが確認すべきは以下の3点です。

• 接続先ホスト：ドメイン or IP
• 接続ポート：22 なのか、2222 等に変えているのか
• 接続元：自宅、社内、踏み台など（IP制限する場合に必要）

2. ufw が原因かどうか確認する（最初にやる）

結論: ufw status verboseでinactiveならufwは原因外、activeなら次のルール確認へ進むことで切り分けが完結する。

ufwが無効なら、ufwは原因ではありません（別要因の可能性が高い）。

$ sudo ufw status verbose

出力例（有効）：

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)

出力例（無効）：

Status: inactive

• inactive → ufw以外（sshd停止、ポート違い、待受なし、クラウド側FWなど）
• active → 次へ（ルール確認）

3. "SSHのポート番号"を確定する（22固定だと事故る）

結論: sshd -T | grep portで実際に採用されているポート番号を確定し、22固定の思い込みによる許可ルール誤設定を防ぐ。

SSHのポートは22が多いですが、セキュリティ目的で変更されていることがあります。

$ sudo grep -nE '^\s*Port\s+' /etc/ssh/sshd_config

追加で確認（includeされている場合に備える）：

$ sudo sshd -T | grep -i '^port '

4. ufw のルールを「番号付き」で確認する

結論: ufw status numberedでSSHポートのALLOW IN有無・DENY混入・接続元IP制限を確認してから操作することで事故を防ぐ。

まずは現状把握です。推測で操作しない。

$ sudo ufw status numbered

見るポイント：

• SSHポート（例：22/tcp または 2222/tcp）が ALLOW IN になっているか
• DENY が入っていないか（優先順位で詰むケースあり）
• From が絞られていないか（自分のIPが変わると繋がらない）

5. 最小の復旧：SSHポートを許可する

結論: まずufw allow <PORT>/tcpで繋がる状態を取り戻してからIP制限などで固めるという順序を守るのが安全。

まず "繋がる状態を取り戻す" のが優先です。その後、IP制限などで固めればOKです。

5-1. 標準22番を許可

$ sudo ufw allow 22/tcp

5-2. 2222番を許可（例）

$ sudo ufw allow 2222/tcp

追加したら必ず確認：

$ sudo ufw status numbered

6. より安全：接続元IPを限定して許可する（推奨）

結論: IP制限はufw allow from <IP> to any port <PORT>で設定するが自宅IP変動に注意しVPN/踏み台との併用を検討する。

SSHはインターネット全開放より、IP制限のほうが堅いです。

$ sudo ufw allow from 203.0.113.10 to any port 2222 proto tcp

7. 「許可したのに繋がらない」原因トップ5

結論: ufw許可後も繋がらない場合はsshd停止・待受なし・クラウドFW・ルール優先順位・IPv6設定の5原因を順に確認する。

原因1：sshd が起動していない / 落ちている

$ sudo systemctl status ssh
$ sudo systemctl start ssh
$ sudo journalctl -u ssh -n 200

原因2：サーバがそのポートで待ち受けていない

$ sudo ss -lntp | grep ':22 '
$ sudo ss -lntp | grep ':2222 '

原因3：クラウド/ホスティング側のFWで止まっている

AWSならセキュリティグループ、GCPならVPC FW、VPSなら管理画面FWなど。ufwだけ直しても外から入れません。

$ nc -vz example.com 2222

• timed out → 経路/FW（クラウド側含む）
• refused → サーバ側で待受なし
• succeeded → ネットワーク的には届いている

原因4：ufwルールの優先順位や deny が効いている

$ sudo ufw status numbered
$ sudo ufw delete 3

原因5：IPv6 側だけ閉じている / 逆にIPv6だけ開いてる

環境によってIPv6が絡みます。statusで Anywhere (v6) も確認します。

8. 失敗例とエラーの読み方

結論: timed outはFW/経路、refusedは待受なし、permission deniedは認証失敗でufwではないと、エラー文から原因の階層が判別できる。

8-1. Connection timed out

意味：パケットが届かない（FW/SG/経路/DNS/相手ダウン）

8-2. Connection refused

意味：到達しているが、そのポートで待受がない

8-3. Permission denied (publickey)

意味：通信は通っているが、認証で落ちている（ufwではない）

8-4. Host key verification failed

意味：known_hostsの不一致（ufwではない）

$ ssh-keygen -R example.com

9. やってはいけないこと

結論: SSH許可前のufw enable・原因不明のdeny量産・IP制限後の自分のIP変動確認漏れが自己ロックアウトを招く典型的な失敗パターン。

やってはいけない1：SSH許可なしで ufw を有効化する

SSHが許可されていない状態で ufw enable をやると、リモートから入れなくなります。

安全な順番：

1. sudo ufw allow <ssh-port>/tcp
2. sudo ufw enable
3. sudo ufw status numbered

やってはいけない2：原因不明のまま deny を量産する

denyが増えると優先順位が絡んで、復旧が遅くなります。

やってはいけない3：IP制限を入れてから「自分のIP」を確認しない

自宅IPが変わりやすいなら、IP制限は"踏み台/VPN"とセットでないと運用事故になります。

# SSH(2222)を全開放で許可（まず復旧）
sudo ufw allow 2222/tcp
sudo ufw status numbered

# SSH(2222)を特定IPだけ許可（運用用）
sudo ufw allow from 203.0.113.10 to any port 2222 proto tcp
sudo ufw status numbered

# denyルールを番号指定で削除
sudo ufw status numbered
sudo ufw delete 3
sudo ufw status numbered

# sshdが起動しているか確認
sudo systemctl status ssh
sudo journalctl -u ssh -n 200
sudo ss -lntp | grep ':2222 '

# クライアント側疎通確認
nc -vz example.com 2222