ポート22（SSH）が外部から接続できない場合の原因と確認手順

SSH で外部からサーバーにつながらないときは、まず ssh コマンドのエラーメッセージを見て「パケットが届いていない（タイムアウト）」のか「届いているが受け付けられていない（拒否）」のかを分けるのが近道です。前者ならクラウドやOSのファイアウォール、接続元のネットワークを、後者なら sshd の状態や待ち受けのポートを調べます。この記事では、メッセージの読み方と、原因を可能性の高い順に確認・修正する手順、作業中に自分を締め出さないための注意点を説明します。

作業の前に：締め出されないための準備

ファイアウォールや sshd の設定を触っていると、設定ミスで唯一の接続手段を失うことがあります。次の2つを先に確保してください。

• 復旧用の経路を確認しておく：VPS のコントロールパネルにあるコンソール機能、AWS の EC2 シリアルコンソールや Systems Manager の Session Manager など、SSH を使わずにログインできる手段
• すでに SSH でつながっているセッションがあれば閉じずに残しておき、設定変更後は別のターミナルから新しく接続して確かめる

設定ファイルを編集する前には、sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak のようにコピーを残しておきます。

エラーメッセージで原因の場所を見分ける

接続元のパソコンから、詳細表示を付けて接続します。

ssh -v -p 22 user@203.0.113.10

最後のほうに出るメッセージで、おおよその原因の場所が分かります。

• Connection timed out：パケットがどこかで捨てられている。クラウドのファイアウォール、OS のファイアウォール、接続元のネットワーク、IP アドレスの誤りを疑う
• Connection refused：サーバーまでは届いているが、そのポートで待ち受けているプロセスがない（または REJECT で拒否されている）。sshd の停止やポート番号の違いを疑う
• No route to host：経路がない、または途中で拒否の応答が返っている。IP アドレスやファイアウォールの REJECT 設定を確認する
• kex_exchange_identification: Connection closed by remote host や Connection reset by peer：TCP はつながったが、sshd またはその手前で切られている。fail2ban などによる遮断、sshd の同時接続数の制限、アクセス制御の設定を疑う
• Permission denied (publickey)：ポートにはつながっていて、認証で失敗している。鍵やユーザー名の問題なので、ポートの問題ではない

Windows の場合は、PowerShell の Test-NetConnection 203.0.113.10 -Port 22 で、TCP の接続が成功するか（TcpTestSucceeded が True か）を確認できます。Linux や macOS では nc -vz 203.0.113.10 22 が同じ用途に使えます。

原因1：クラウドや VPS のファイアウォールで閉じている

外部からつながらない原因として最も多いのが、OS より手前にあるネットワーク側のファイアウォールです。AWS のセキュリティグループやネットワーク ACL、Google Cloud の VPC ファイアウォールルール、Azure のネットワークセキュリティグループ、国内 VPS のコントロールパネルにあるパケットフィルターなどがこれに当たります。

確認するのは、受信（インバウンド）ルールに TCP 22番（または変更後のポート）が許可されているか、そして許可している接続元の IP アドレスが今の自分の IP と一致しているかです。自宅や事務所の回線の IP が変わったために、以前許可した IP から外れていた、という例はよくあります。今の自分の IP は、接続元のパソコンからブラウザの「IP 確認」サービスなどで調べられます。

セキュリティの面からは、22番ポートをすべての送信元（0.0.0.0/0）に開けるのは避け、自分の IP や VPN の出口など必要な範囲に絞るのが基本です。

原因2：OS のファイアウォールで閉じている

サーバーにコンソールからログインし、OS のファイアウォールを確認します。使っている仕組みに合わせて実行してください。

# Ubuntu / Debian（ufw）
sudo ufw status verbose

# RHEL / AlmaLinux / Rocky Linux（firewalld）
sudo firewall-cmd --list-all

# nftables を直接使っている場合
sudo nft list ruleset

許可がない場合は追加します。ufw を新たに有効にするときは、有効化より前に SSH の許可を入れておかないと、その瞬間に接続が切れます。

# ufw：SSH を許可してから有効化する
sudo ufw allow OpenSSH
sudo ufw enable

# firewalld：ssh サービスを恒久的に許可して反映する
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

ポートを 22 以外に変えている場合は、サービス名ではなくポート番号（例: sudo ufw allow 2222/tcp）で許可します。

原因3：sshd が動いていない、または別のポートで待ち受けている

Connection refused の場合は、sshd の状態と、実際に待ち受けているポートを確認します。

# サービスの状態（ディストリビューションにより ssh または sshd）
sudo systemctl status ssh
sudo systemctl status sshd

# 実際に待ち受けているポートとアドレス
sudo ss -tlnp | grep -i ssh

# 設定ファイルの最終的な値（文法エラーがあればここで分かる）
sudo sshd -t
sudo sshd -T | grep -E "^(port|listenaddress) "

ss の結果が 127.0.0.1:22 だけになっている場合は、ListenAddress の設定で外部からの待ち受けが無効になっています。また、Ubuntu の新しめのバージョン（22.10 以降）では、sshd がソケットアクティベーション（ssh.socket）で起動する構成が標準になっており、sshd_config の Port を変えたあとに sudo systemctl daemon-reload と sudo systemctl restart ssh.socket が必要になる場合があります。設定を変えたのに待ち受けのポートが変わらないときは、この点を確認してください。

RHEL 系でポートを変更した場合は、SELinux が新しいポートでの待ち受けを拒否することがあります。sudo semanage port -a -t ssh_port_t -p tcp 2222 のように、使うポートを SSH 用として登録します。

原因4：fail2ban などで自分の IP が遮断されている

パスワードや鍵を何度か間違えたあとに急につながらなくなった場合は、fail2ban などの不正ログイン対策ツールが自分の IP を遮断している可能性があります。

sudo fail2ban-client status sshd
# 自分の IP が含まれていれば解除する
sudo fail2ban-client set sshd unbanip 198.51.100.20

解除しても同じことを繰り返さないよう、接続に使う鍵とユーザー名を確認してから再度試してください。

原因5：パケットがサーバーまで届いていない

ここまでで原因が見つからない場合は、サーバー側でパケットが届いているかを直接見ます。コンソールで次を実行したまま、外部から接続を試します。

sudo tcpdump -ni any tcp port 22

何も表示されなければ、パケットはサーバーに届く前に止まっています。クラウドのファイアウォールを再確認するほか、接続先の IP アドレスが正しいか（インスタンスを停止・起動して公開 IP が変わっていないか、DNS の名前が古い IP を指していないか）、接続元のネットワークが外向きの22番を禁止していないかを確かめます。会社や公共の Wi-Fi では、外向きの SSH を遮断していることがあります。スマートフォンのテザリングなど別の回線から試すと切り分けられます。IPv6 で接続しようとしている可能性もあるので、ssh -4 で IPv4 に限定して試すのも有効です。

パケットは届いているのに応答がない場合は、OS のファイアウォールか sshd 側に戻って確認します。

復旧したあとに見直したいこと

つながるようになったら、同じ問題を防ぐために設定を見直します。公開鍵認証に切り替えてパスワード認証を無効にする、root での直接ログインを禁止する、接続元の IP を絞る、といった対策が基本です。ポート番号を変えるとログに残る攻撃の試行は減りますが、それだけでは防御にならないので、ほかの対策と組み合わせてください。各ディストリビューションの sshd の既定値や起動方式はバージョンによって異なるため（2026年10月現在）、利用中のバージョンのドキュメントも確認してください。

まとめ

• ssh -v のメッセージで、タイムアウト（届いていない）と拒否（届いているが受け付けない）を分ける
• 最も多いのはクラウド・VPS のファイアウォール。許可した接続元 IP が今の IP と一致しているかを見る
• OS のファイアウォールは、有効化より前に SSH の許可を入れる
• ss と sshd -T で待ち受けのポートとアドレスを確認する。Ubuntu の ssh.socket と SELinux に注意する
• 作業前に、コンソールなど SSH 以外の復旧経路と、既存のセッションを確保しておく

• ufw でファイアウォールを設定する手順
• SSH のポート番号を変更する手順と注意点