SSH接続できないときは、やみくもに設定を触るよりも、bashで確認すべきポイントを上から順に潰すのが最短です。
特に初動では、「自端末の問題なのか」「ネットワークなのか」「認証なのか」を切り分けられるかどうかが復旧スピードを左右します。
ここでは SSH接続できない状態を、DNS・疎通・経路・ポート・認証の順で切り分けるチェックリストを示します。
よくある症状（timeout / refused / permission denied）
SSHトラブルは、エラーメッセージから大まかな当たりを付けられます。
- Connection timed out
通信が相手に届いていない可能性が高く、経路やファイアウォールを疑います。 - Connection refused
相手ホストには到達しているが、SSHポートが閉じている、または sshd が動いていない状態です。 - Permission denied (publickey/password)
ネットワークは問題なく、ユーザー名・鍵・権限など認証周りが原因のケースです。
このあと、これらの症状を bashコマンドで一つずつ切り分けていく手順に進みます。
SSH接続できないときのbashチェック手順（上から実行）
SSHが繋がらないときは、下からではなく上から確認します。
DNS → 疎通 → 経路 → ポート → 認証の順で切り分けると、原因を最短で特定できます。
まずは「相手に辿り着けているか」を確認します。ここで詰まる場合、認証以前の問題です。
1. DNSが引けているか
getent hosts example.com
IPが返らない場合は、DNS設定や名前解決が原因です。
IP直指定でSSHできるかも併せて確認すると切り分けが早くなります。
ssh user@203.0.113.10
2. ネットワーク疎通（ICMP）
ping -c 3 example.com
応答があれば疎通は問題なしです。
応答がなくても、ICMPを遮断している環境はあるため、次の確認へ進みます。
3. 経路の確認
traceroute example.com
途中で止まる場合は、ルーターやネットワーク経路に問題がある可能性があります。
クラウド環境では途中が見えなくても、最終ホップまで到達していれば次に進みます。
4. SSHポート（22/TCP）に到達できるか
nc -vz example.com 22
または telnet が使える場合は以下でも確認できます。
telnet example.com 22
succeeded/ 接続できる → ポートは開いているtimed out→ ファイアウォールやセキュリティグループを疑うrefused→ sshd が停止している、または待ち受けポートが違う
ここまで通れば、ネットワーク的には問題なしと判断できます。
認証（鍵・ユーザー・権限）を確認するコマンド
ネットワークが問題なければ、次は認証です。ssh -v を使うと、どこで失敗しているかが分かります。
ssh -v user@example.com
特に以下の行を確認します。
Authentications that can continue:
→ サーバー側が許可している認証方式Offering public key:
→ クライアントが鍵を提示しているかPermission denied
→ ユーザー名、鍵、権限のどれかが不正
使用している鍵を明示するのも有効です。
ssh -i ~/.ssh/id_ed25519 user@example.com
また、秘密鍵の権限が緩すぎると拒否されます。
ls -l ~/.ssh/id_ed25519
chmod 600 ~/.ssh/id_ed25519
ここで失敗する場合、原因はほぼ ユーザー名・公開鍵・権限・sshd設定のいずれかに絞られます。
典型エラー別の当たりどころ（timeout / refused / host key / permission）
ここまでのチェック結果と、SSHのエラーメッセージを組み合わせると、疑うべき場所がほぼ一意に決まります。
代表的なエラーごとに、bashで見るべき当たりどころを整理します。
タイムアウト時は「経路・FW・ポート」を疑う
ssh: connect to host example.com port 22: Connection timed out
この場合、相手に到達できていないのが原因です。
pingが通らないnc -vz example.com 22が timeout- クラウドやVPSでセキュリティグループを変更した直後
まずは以下を確認します。
- ローカル／中継ネットワークでの通信遮断
- サーバー側のファイアウォール設定
（ufw statusやiptables -Lで22番が許可されているか） - SSHポート番号が22以外に変更されていないか
ポート番号が違う場合は、明示して接続します。
ssh -p 2222 user@example.com
拒否や認証失敗は「sshd・ユーザー・鍵・権限」を疑う
ssh: connect to host example.com port 22: Connection refused
この場合、ホストには到達しているがSSHが受け付けていません。
- sshd が停止している
- SSHの待ち受けポートが変更されている
- サーバー起動直後でサービスが未起動
サーバーにコンソール接続できる場合は、以下を確認します。
sudo systemctl status sshd
次に多いのが認証エラーです。
Permission denied (publickey)
この場合はネットワークではなく、認証設定の問題です。
- ユーザー名が違う
- 公開鍵が
authorized_keysに登録されていない .sshやauthorized_keysの権限が不正sshd_configで公開鍵認証が無効
ssh -v の出力を見て、どこで弾かれているかを確認すると切り分けが一気に進みます。
Host key verification failed
これは 既存のホスト鍵と一致しないときに出ます。
サーバーを再構築した直後によく起きるため、以下で該当エントリを削除します。
ssh-keygen -R example.com
その後、再接続すれば新しいホスト鍵が登録されます。
まとめ
SSH接続できない原因はネットワーク側か認証側かに切り分けると、復旧までの時間を大きく短縮できます。
SSHが繋がらないときは、
DNS → 疎通 → 経路 → ポート → 認証
の順でbashコマンドを実行するだけで、問題の所在はほぼ特定できます。
もしネットワーク側が原因なら、ufw 設定 確認を、
認証側が原因ならssh 公開鍵 認証 設定やsshd_config 設定を確認し、該当箇所を一気に詰めていきましょう。
