ping、tracerouteコマンドを使用した、SSHできない時の切り分け方

Posted at 2026-06-07

はじめに

インフラ構築をしていると、よくあるトラブルのひとつに「SSHできない」があります。

たとえば、新しく作成したLinuxサーバにSSHしようとしたとします。

ssh user@192.168.1.100

しかし、しばらく待っても接続できず、次のようなエラーが返ってきます。

ssh: connect to host 192.168.1.100 port 22: Connection timed out

「サーバが落ちているのかな？」と思って ping を実行すると、応答は返ってきます。

ping 192.168.1.100
64 bytes from 192.168.1.100: icmp_seq=1 ttl=64 time=1.2 ms

ここで初心者が悩みやすいのが、

pingは通るのに、なぜSSHできないのか？

という点です。

実は、pingが通ることとSSHできることは別の話です。

この記事では、ping・traceroute・SSH を使って、SSHできないときにどこまで通信できているのかを切り分ける考え方を整理します。

この記事でわかること

ping で何がわかるのか
traceroute で何がわかるのか
SSHのエラーから何を疑えばよいのか
pingが通ってもSSHできない理由
どの順番で確認すればよいのか
AWS環境で見るべきポイント

まず結論

SSHできないときは、次のように分けて考えると整理しやすいです。

確認	コマンド例	わかること
到達	`ping <IP>`	相手からICMPの応答が返るか
経路	`traceroute <IP>`	途中のどこまで応答が返るか
ポート	`nc -vz <IP> 22` / `telnet <IP> 22`	TCP 22番に届くか
SSH接続	`ssh -v user@<IP>`	SSH接続や認証のどこで失敗しているか

大事なのは、それぞれ確認しているものが違うということです。

pingが通るからといって、SSHできるとは限らない
tracerouteが途中で止まるからといって、必ずSSHできないとも限らない
SSHできない原因は、ネットワーク・ポート・サービス・認証などに分けて考える必要がある

1. SSHできない原因は1つではない

SSHできない原因は、ざっくり分けると以下です。

分類	例
経路の問題	ルートがない、途中のNW機器で止まっている
FW/SG/NACLの問題	TCP 22番が許可されていない
サーバ側の問題	sshdが起動していない
認証の問題	ユーザー名、鍵、パスワードが違う
名前解決の問題	ホスト名が意図したIPに解決されていない

つまり、単に「SSHできない」といっても、見るべき場所は複数あります。

そのため、いきなりSSH設定だけを見るのではなく、どこまで通信できていて、どこから先ができていないのか
を順番に確認していくことが大切です。

2. pingでわかること

ping は、相手のIPアドレスに対してICMPという通信を送り、応答が返ってくるかを確認するコマンドです。

ping 192.168.1.100

応答が返ってくる場合は、少なくともICMPでは相手から応答が返ってきています。

64 bytes from 192.168.1.100: icmp_seq=1 ttl=64 time=1.2 ms

この場合、次のように考えられます。

宛先IPは大きく間違っていなさそう
相手から応答が返ってきている
ICMP通信は許可されていそう

ただし、ここで重要なのは、

pingが通る ≠ SSHできる

ということです。pingとSSHは使っている通信が違います。

種類	使用するもの
ping	ICMP
SSH	TCP 22番

そのため、pingが通っても、TCP 22番が閉じていればSSHはできません。

逆に、pingが通らなくてもSSHできる場合もあります。
セキュリティ設定でICMPだけ拒否し、SSHのTCP 22番だけ許可している構成が当てはまります。

3. tracerouteでわかること

traceroute は、宛先までの途中経路で、どこから応答が返っているかを確認するコマンドです。

Linuxでは以下のように実行します。

traceroute 192.168.1.100

Windowsの場合は tracert を使います。

tracert 192.168.1.100

結果例です。

traceroute to 192.168.1.100 (192.168.1.100), 30 hops max
 1  192.168.0.1  1.123 ms  1.045 ms  1.001 ms
 2  10.0.0.1     3.456 ms  3.421 ms  3.398 ms
 3  * * *
 4  * * *

* * * は、その地点から応答が返ってこなかったことを表します。

この例では、2番目の経路までは応答がありますが、3番目以降で応答が返っていません。

ただし、ここも注意が必要です。

tracerouteで * * * が出る ≠ 必ず通信不可

途中のルーターやファイアウォールが、tracerouteへの応答だけ返さない設定になっていることがあります。そのため、途中で * * * が出ても、最終的に宛先へ通信できるケースもあります。

4. tracerouteで見るポイント

初心者のうちは、細かい経路をすべて理解しようとしなくても大丈夫です。まずは以下を見るとよいです。

見るポイント	意味
1行目に応答があるか	自分の近くのゲートウェイまでは行けていそうか
途中から `* * *` が続くか	途中で応答が返らなくなっている
最終的に宛先IPが表示されるか	宛先まで応答が返っている
想定外の経路を通っていないか	ルーティングが想定と違う可能性

ただし、tracerouteはあくまで経路確認のヒントです。SSHで使うTCP 22番ポートが通るかどうかは、別途確認する必要があります。

5. SSHのエラーを見る

SSHできないときは、まずエラーメッセージを確認します。

Connection timed out

ssh: connect to host 192.168.1.100 port 22: Connection timed out

SSH接続の応答が返ってきていない状態です。よくある原因は以下です。

TCP 22番がファイアウォールで止められている
AWSの場合、Security Groupで22番が許可されていない
Network ACLで拒否されている
サーバが停止している
経路や戻りの通信に問題がある

Connection refused

ssh: connect to host 192.168.1.100 port 22: Connection refused

相手には届いているものの、22番ポートで受け付けていない可能性があります。よくある原因は以下です。

sshdが起動していない
SSHの待ち受けポートが22番ではない
サーバ側で接続を拒否している

Permission denied

Permission denied (publickey).

SSHサーバには届いているが、認証に失敗している状態です。よくある原因は以下です。

ユーザー名が違う
秘密鍵が違う
公開鍵がサーバに登録されていない
authorized_keys の権限が不適切
パスワード認証が無効になっている

この場合、ネットワークよりも認証設定を疑います。

6. 22番ポートに届くか確認する

ping と traceroute だけでは、SSHのTCP 22番ポートに届くかは判断できません。そのため、nc または telnet で22番ポートを確認します。

ncを使う場合

nc -vz 192.168.1.100 22

成功例

Connection to 192.168.1.100 22 port [tcp/ssh] succeeded!

この場合、TCP 22番ポートまでは届いています。それでもSSHできない場合は、ユーザー名・鍵・認証方式などを確認します。

失敗例

nc: connect to 192.168.1.100 port 22 timed out

TCP 22番への通信が返ってきていません。以下を確認します。

Security Group
Network ACL
OS側ファイアウォール
ルートテーブル
サーバの起動状態
sshdの起動状態

telnetを使う場合

telnet 192.168.1.100 22

成功すると、SSHサーバのバナーが表示されることがあります。

SSH-2.0-OpenSSH_8.9

この表示が出れば、SSHサーバの22番ポートまでは届いています。

7. 切り分けフロー

SSHできないときは、以下の順番で確認すると整理しやすいです。

① SSHのエラーを見る
  ├─ Permission denied
  │   └─ 認証、ユーザー名、鍵を確認
  │
  ├─ Connection refused
  │   └─ sshd起動状態、待ち受けポートを確認
  │
  └─ Connection timed out
      └─ 経路、FW、SecurityGroup、NACL、サーバ状態を確認


② pingで応答を確認
  ├─ 応答あり
  │   └─ ICMPでは応答が返っている。ただしSSH可能とは限らない
  │
  └─ 応答なし
      └─ ICMP拒否、経路問題、サーバ停止などを疑う


③ tracerouteで経路を確認
  ├─ 宛先まで表示される
  │   └─ 経路は大きく問題なさそう
  │
  ├─ 途中で * * * が続く
  │   └─ 途中機器が応答しない、または経路/FWの問題を疑う
  │
  └─ 最初から応答がない
      └─ 自端末側、ゲートウェイ、ルート設定を確認


④ 22番ポートを確認
  ├─ 接続成功
  │   └─ 認証やSSH設定を確認
  │
  ├─ timed out
  │   └─ FW、SecurityGroup、NACL、経路を確認
  │
  └─ refused
      └─ sshd停止、待ち受けポート違いを確認

8. 判断表

ping	traceroute	22番ポート	SSH	考えられる原因
成功	宛先まで見える	成功	成功	問題なし
成功	宛先まで見える	成功	Permission denied	認証情報の問題
成功	宛先まで見える	refused	失敗	sshd停止、待ち受けポート違い
成功	宛先まで見える	timed out	失敗	TCP 22番だけFWで拒否
成功	途中で止まる	成功	成功/失敗	traceroute応答だけ拒否の可能性
失敗	途中で止まる	timed out	失敗	経路、FW、SG、NACL、戻り経路の問題
失敗	途中で止まる	成功	成功	ICMP/tracerouteだけ拒否されている可能性
失敗	失敗	失敗	失敗	宛先IP誤り、サーバ停止、経路なしの可能性

9. AWS環境で見るポイント

AWS上のEC2へSSHできない場合は、OS内だけではなくAWS側の設定も確認します。

確認箇所	見るポイント
Security Group	インバウンドでTCP 22番が許可されているか
Network ACL	サブネット単位で拒否されていないか
ルートテーブル	接続元から対象サブネットへの経路があるか
サブネット	パブリック/プライベートの配置が想定通りか
Internet Gateway / NAT / TGW / Peering	経路上に必要な接続があるか
EC2の状態	インスタンスが起動しているか
OS側FW	firewalld、iptables、ufwなどで拒否されていないか
sshd	SSHサービスが起動しているか
鍵・ユーザー名	正しい秘密鍵、正しいユーザー名を使っているか

特にAWSでは、以下のようなケースがよくあります。

Security Groupで22番が許可されていない
接続元IPが変わっていて許可CIDRから外れている
Network ACLの戻り通信が許可されていない
ルートテーブルに戻り経路がない
踏み台サーバ経由の経路が想定と違う
EC2は起動しているがsshdが停止している

AWSでは、サーバの中だけを見ても原因がわからないことがあります。VPC・サブネット・ルートテーブル・Security Group・NACLもセットで確認するのが大切です。

10. 初心者向けに一番伝えたいこと

SSHできないときに一番大事なのは、

何ができていて、何ができていないのかを分けて考える

ことです。

ping は、ICMPの応答を見る
traceroute は、途中経路の応答を見る
nc や telnet は、TCP 22番ポートに届くかを見る
ssh は、SSH接続と認証まで含めて確認する

つまり、それぞれ確認している範囲が違います。

コマンド	確認できること	確認できないこと
`ping`	ICMPの応答	SSHできるか
`traceroute`	途中経路の応答	TCP 22番が通るか
`nc -vz <IP> 22`	TCP 22番の疎通	認証が成功するか
`ssh -v user@<IP>`	SSH接続と認証の詳細	経路全体の詳細

1つのコマンドだけで判断するのではなく、どこまで確認できていて、どこから先が未確認なのかを意識すると、トラブルシュートがかなり楽になります。

まとめ

SSHできないときは、以下の流れで確認すると原因を絞りやすくなります。

SSHのエラー内容を見る
ping でICMPの応答を確認する
traceroute で途中経路を確認する
nc や telnet でTCP 22番ポートを確認する
22番まで届くなら、ユーザー名・鍵・認証設定を確認する
AWS環境では、Security Group・NACL・ルートテーブルも確認する

pingが通ることは、SSHできることの証明ではありません。
tracerouteが途中で止まることも、必ずしも通信不可の証明ではありません。

大事なのは、各コマンドが何を確認しているのかを理解し、順番に切り分けることです。

「SSHできない」という曖昧な状態を、

ICMPは返る
経路はここまで見える
TCP 22番は届かない
22番は届くが認証で失敗している

のように分解できると、原因に近づきやすくなります。
インフラ構築を始めた頃は、SSHできなかった時に、先輩に「pingは？」「tracerouteは？」など聞かれてから確認することがありましたが、切り分け方法がわかれば、それでもSSHできなかった時に「ここまで確認しました！」と伝えられるので対応がスムーズに進められると思います。

未経験から学べます！一緒に挑戦していきましょう

noteもやってます↓
https://note.com/jqit_itsaiyo

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up