【Ubuntu】ufw でSSHが繋がらない時：許可ルールの確認と戻し方（事故らない手順）

ufw トラブルシューティング - SSH接続
読了時間: 約12分 難易度: 中級

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

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

結論（最短ルート）

SSHが繋がらない時は、これを上から順にやるのが最も安全です。

  1. SSHのポート番号を確定（22とは限らない）
  2. ufwが原因か確認：sudo ufw status verbose
  3. 許可ルールを確認：sudo ufw status numbered
  4. 必要な許可を追加：sudo ufw allow <PORT>/tcp
  5. まだダメなら"ufw以外"を疑う（ポート待受、sshd、セキュリティグループ等）

重要

この記事は「サーバ側に入れる状態（コンソール/別経路でログイン可）」を前提に書いています。既にSSHで入れないなら、クラウドのコンソールやVPSのWebコンソール等で作業してください。

目次

  1. まず状況を整理
  2. ufw が原因かどうか確認する
  3. SSHのポート番号を確定する
  4. ufw のルールを確認する
  5. SSHポートを許可する
  6. 接続元IPを限定して許可する
  7. 「許可したのに繋がらない」原因トップ5
  8. 失敗例とエラーの読み方
  9. やってはいけないこと

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

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

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

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

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固定だと事故る）

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

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

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

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

sshd -T は "sshdが実際に採用している設定" を出してくれるので確実です。

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

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

$ sudo ufw status numbered

見るポイント：

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

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

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

5-1. 標準22番を許可

$ sudo ufw allow 22/tcp

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

$ sudo ufw allow 2222/tcp

追加したら必ず確認：

$ sudo ufw status numbered

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

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

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

注意：自宅回線のIPが変わる環境だと、翌日繋がらなくなることがあります。その場合は「固定IP」「VPN」「踏み台」なども検討対象です。

7. 「許可したのに繋がらない」原因トップ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. 失敗例とエラーの読み方

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. やってはいけないこと

やってはいけない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

まとめ

  • ufwのトラブルは 「ufw有効か」→「SSHポート確定」→「ルール確認」→「許可追加」 の順で潰す
  • timed out / refused / publickey の違いで、原因の階層が分かる
  • いきなり ufw enable/deny でいじらず、番号付きで現状確認してから操作する

次に読む（関連記事）

検証環境

本記事のコマンドは Ubuntu 24.04 LTS / bash 5.2 で動作確認済みです。

次に読む