LinuxサーバーでSSH接続が拒否されるときの5つの切り分け方法

Linux VPS を契約した直後、あるいは深夜に監視アラートで「SSH が入れない」と知らされる場面——ターミナルに ssh: connect to host … port 22: Connection refused と出た瞬間、心臓が少し速くなるのは誰もが同じです。さらに VNC もクラウドコンソールも手元になければ、黒い画面を睨むしかありません。

現場では月に何度かこの相談を受けます。sshd_config を直したあと reload を忘れた、セキュリティグループで 80/443 だけ開けて 22 を忘れた、fail2ban が自宅回線の IP を黙って ban した——原因はバラバラですが、Connection refused はだいたい筋道が通っています。本記事では実戦で効く五つの切り分け手順を、エラーを読んでから層ごとに降りる順で整理します。多くのケースは二十分以内に原因が見えます。

前提として、別ルートでサーバーに触れる手段（クラウド VNC、シリアルコンソール、同一 VPC 内の別マシン）がある想定です。完全に手が届かない場合は、文末の「完全に遮断されたとき」へ進んでください。

切り分けの前に：「繋がらない」は三種類ある

Connection refused、Connection timed out、Permission denied を同じ問題として扱うと、一時間キーファイルを疑い続けることになります。OpenSSH 公式ドキュメントの意味づけに沿うと、それぞれ別レイヤーを指します。

この区別を最初に押さえるだけで、無駄な作業が大きく減ります。Connection refused はパケットがサーバーに届いているサイン——問題はサーバー側か、そのすぐ手前です。timed out は経路上のどこかで黙殺されているので、届かないマシンの sshd_config をいじっても意味がありません。Permission denied は TCP セッションは成立しているので、認証情報・アカウント方針・IP ban を疑います。

チーム運用では、インシデントチャットにエラー全文を貼ってください。「SSH 死んだ」だけでは当たりがつきません。「オフィス IP から 2222 で Connection refused」なら、検索範囲が一気に狭まります。

手順 1：IP・DNS・ポート到達性の確認（ネットワーク層）

sshd を疑う前に、道が通っているかを示してください。新規 VPS で多いのは IP の打ち間違い、DNS 未反映、非標準ポートで待ち受けているのに 22 で繋いでいるパターンです。

手元の PCから、次の順で実行します。

# 1. 名前解決された IP が正しいか
                dig +short your.domain.com
                ping -c 3 your.server.ip

                # 2. SSH ポートが開いているか（22 は実際のポートに置き換え）
                nc -zv your.server.ip 22
                # または
                telnet your.server.ip 22

                # 3. ポートを明示して接続（~/.ssh/config の影響を避ける）
                ssh -p 22 -i ~/.ssh/id_ed25519 user@your.server.ip

nc が Connection refused を返すなら、パケットはサーバーに届いています——原因は本機サービスか本機ファイアウォールです。手順 2 へ。timed out やハングなら、クラウドのセキュリティグループ／Network ACLを優先：入站で TCP 22（またはカスタムポート）が許可されているか、送信元が 0.0.0.0/0 か、誤ってプライベート帯だけになっていないかを確認します。

自宅・会社の回線も見落としがちです。企業 VPN、学園ネット、一部 ISP は 22 をフィルタします。一時的に sshd を 443 や 2222 に移して比較テストすると、経路側のフィルタかサーバー本体かが切り分けやすくなります。

複数台を運用しているなら、公開 IP と SSH ポートのメモを残しておくと、旧チケットから IP をコピペして繋がらなくなる事故が減ります。ホスト名接続では TTL とキャッシュも忘れずに——レジストラで直した直後でも、手元の dig +short が古いアドレスを指していることがあります。

手順 2：sshd サービスの稼働確認

Connection refused の最多原因のひとつ：sshd が起動していない、または OS アップグレード後にユニット名が変わったケースです。Ubuntu/Debian では ssh、RHEL/CentOS/Rocky では sshd が一般的——推測せずコマンドで確認してください。

VNC やクラウドコンソールで入ったあと、次を実行します。

# Debian/Ubuntu
                sudo systemctl status ssh
                sudo systemctl start ssh
                sudo systemctl enable ssh

                # RHEL/CentOS/Rocky
                sudo systemctl status sshd
                sudo systemctl start sshd

                # 待ち受けているか？ アドレスとポートは？
                sudo ss -tlnp | grep ssh
                # 0.0.0.0:22 または [::]:22 が期待値

                # 設定構文チェック（編集のたびに実行）
                sudo sshd -t
                sudo systemctl reload ssh   # または sshd

systemctl status が failed なら、すぐ sudo journalctl -u ssh -n 50 --no-pager でログを確認。設定の typo、HostKey ファイル欠落、ListenAddress の誤った NIC 指定が典型です。修正後は必ず sshd -t → reload の順——reload だけして sshd が起動せず、自分を締め出すパターンは現場で本当に多いです。

再インストール直後は openssh-server の有無も確認：sudo apt install openssh-server（Debian 系）、sudo dnf install openssh-server（RHEL 系）。最小イメージは SSH サーバー無しで届くことがあります。

ディスク満杯でも sshd が起動しない・セッションを張れないことがあります。コンソールで df -h を見るだけで十分なことが多いです。MaxStartups を攻撃対策で絞りすぎると、負荷時に正当な接続まで refused になることも——journalctl の drop 系メッセージを確認してください。

手順 3：本機ファイアウォールとクラウドセキュリティグループ

sshd は動いていて ss にも LISTEN が見えるのに外から refused——次はパケットを捨てる／拒否するルールです。Linux サーバーではクラウド SG（NIC 外側）と ufw/iptables/nftables（OS 内側）の二重構造が普通で、両方で SSH ポートを許可する必要があります。

OS 内での代表的な確認：

sudo ufw status verbose
                sudo ufw allow 22/tcp
                sudo ufw allow 2222/tcp   # ポート変更時
                sudo ufw reload

                # firewalld（CentOS など）
                sudo firewall-cmd --list-all
                sudo firewall-cmd --permanent --add-service=ssh
                sudo firewall-cmd --reload

                # nftables/iptables を直接確認
                sudo iptables -L INPUT -n -v

クラウド SG は SSH が死んでいるとプロバイダコンソールからしか直せません。TCP であること、ポート範囲に SSH ポートが含まれること、送信元 CIDR が一台の内部ネットワークホストだけに狭まっていないことを確認。検証中は一時的に 0.0.0.0/0 で開け、接続確認後にオフィス出口 IP へ絞るのが安全です。

Docker や Kubernetes を載せていると iptables が自動書き換えされます。sudo iptables-save | grep 22 で ACCEPT より前に DROP/REJECT が挿さっていないかを見てください。最小露出と SSH／HTTPS のポート設計については、OpenClaw Linux クラウド VPS 最小露出：ファイアウォール雛形と SSH／HTTPS 意思決定マトリクス FAQも併読すると判断が早くなります。

IPv6 の見落としも定番です。IPv4 の SG だけ直して、クライアントが AAAA 経由で繋ごうとして v6 側が塞がれている——ssh -4 と ssh -6 で挙動が変わるか試す価値があります。

どの層で塞がれていたかを記録しておくと、次に誰かが「セキュリティ強化」したとき同じ outage を繰り返しにくくなります。ufw だけ直して SG を忘れるチームは、半年後にまた同じ話をします。

手順 4：ポートと sshd_config の突合

セキュリティのため 22 以外に移した、ListenAddress を内部ネットワークだけにした——のにクライアントは 22 のまま、というのは refused の定番です。設定は /etc/ssh/sshd_config。主要項目（詳細は sshd_config マニュアル）：

Port 2222
                # ListenAddress 0.0.0.0   # 既定は全 NIC；127.0.0.1 だと外から入れない
                PermitRootLogin prohibit-password
                PasswordAuthentication no
                AllowUsers deploy admin

安全なポート変更の順序：新ポートで LISTEN を確認 → ファイアウォール更新 → 旧ポートを閉じる。いきなり「22 を 2222 に変えて SG の 22 も閉じる」と、新ポートの検証前に締め出されます。

RHEL 系で SELinux 有効時は、ポート変更後に sudo semanage port -a -t ssh_port_t -p tcp 2222 が必要なことがあります。Ubuntu の AppArmor もパス制限でログに明示されます。

クライアントの ~/.ssh/config で Port や HostName が誤っていないかも確認。Host prod エイリアス運用で -p を付け忘れるのは、チームあるあるです。

AllowUsers／DenyUsers の変更直後は、TCP は通るのに認証で落ちる——あるいは早期切断——ように見えることがあります。ローカルのユーザー名とサーバー側許可リストを突き合わせてください。踏み台や ProxyJump 構成では、最終ホップだけ refused という見え方もします。各段を nc と ssh -J で個別に試すと早いです。

手順 5：IP 封鎖の確認（fail2ban / hosts.deny）

refused ではなく Permission denied なのに鍵は正しいはず——なら IP ban を疑います。fail2ban はパスワード失敗や異常ハンドシェイのあと iptables や hosts.deny にルールを足します。fail2ban Wiki に jail の仕組みがまとまっています。

サーバー上で確認：

# fail2ban 状態
                sudo fail2ban-client status sshd
                sudo fail2ban-client set sshd unbanip YOUR.CLIENT.IP

                # 従来の hosts ベース封鎖
                grep -v '^#' /etc/hosts.deny
                grep -v '^#' /etc/hosts.allow

                # クラウドの「運用ロック」や DDoS 緩和
                # → コンソールでセキュリティアラート・一時 IP ブロックを確認

自分で自分を ban するのは珍しくありません。スクリプトの誤動作で短時間に大量の失敗ログが出ると、オフィス出口 IP が jail に入ります。解除後は ignoreip に管理者ネットを入れるか、パスワード認証を切って鍵のみにすると誤検知が減ります。

Jenkins や GitLab Runner など、VPS へ SSH バックする Agent を併用していると、登録失敗が SSH 異常に見えることもあります。ハイブリッド構成では Controller と Agent の経路を別図にした方がよい——Jenkins ハイブリッドトポロジ：VPS Controller とクラウド Mac JNLP エンタープライズプールを参照してください。

完全に遮断されたとき：救援ルートを使う

五手順でも戻れない場合、優先度順に試します。

• クラウド VNC／シリアルコンソール——SSH に依存せず直接ログインして設定修正
• スナップショット復元——変更前に撮っていれば、徹夜より安い
• シングルユーザーモード／レスキューイメージ——元ディスクをマウントして chroot し sshd_config を編集
• サポートチケット——ベンダーが一時的にポート開放やブロック解除してくれる場合あり

教訓は一つ：唯一の SSH セッションで「切れるかもしれない変更」をしない。第二ターミナルを開く、tmux を使う——ファイアウォールと sshd の編集は特にそうです。

復旧後は三行の振り返りを残すと、次のオンコールが助かります。何を変えたか、どの信号を見逃したか、どのバックアップ経路が効いたか——だけで十分です。

予防チェックリスト：次の慌てを減らす

インシデント後に十分だけ手を入れると、次回のパニックが安くなります。

• 鍵認証＋パスワード無効、~/.ssh/authorized_keys は 600
• 非標準ポートは可——セキュリティグループと sshd_config を同時に変更
• fail2ban の ignoreip に信頼ネットワークを登録
• reload 前に sshd -t、危険な変更前にスナップショット
• 監視は SSH 22 の生死だけに頼らず、Agent や内部ネットワークヘルスチェックを併用

固定出口 IP の踏み台を一台用意し、本番ノードの SG はそこからだけ許可する——カフェの Wi‑Fi IP を唯一の鍵にしない、という設計が長期的に楽です。