SSH接続できない原因と確認手順
このページの目的
SSH接続失敗を「接続先へ届かない」「22番ポートでSSHを受け付けていない」「SSHの認証で拒否されている」に分け、エラー文だけで原因を決めつけず、確認結果から次に見る場所を決められるようにします。
最初にやること
ssh -vvv で詳細ログを取り、あわせて nc -vz 接続先 22 でTCP接続できるか確認します。まず「通信段階」と「認証段階」を分けます。
Permission denied になる場合は、Permission deniedの切り分けガイドを確認してください。接続元CIDRを確認
Firewallやクラウド側の許可ルールで、接続元IPが許可ネットワークに含まれているかCIDR計算ツールで確認できます。
最初に失敗している段階を分ける
SSHは、接続先までの通信、TCPポートへの接続、SSHプロトコルの開始、ユーザー認証という順に進みます。最初にどの段階で止まっているかを確認すると、設定を闇雲に変更せずに済みます。
- 22番ポートへ接続できない：経路、Firewall、sshdの待受、SSHポート変更を優先して確認
- SSHのバナーや鍵交換まで進む：ネットワークよりもsshd設定・ユーザー認証・鍵を優先
- ログイン後だけ操作できない：SSH接続の問題ではなく、OS側の権限やSELinuxを確認
よくあるSSHエラー・症状
表示は原因を断定するものではありません。どの段階で失敗しているかを絞るための手掛かりとして使います。
| エラー・症状 | 考えられる原因 | 最初の確認方法 |
|---|---|---|
Connection timed out | Firewall・ACLでのDROP、22番ポート以外を使用、経路や戻り通信の問題 | nc -vz 接続先 22 と接続先側の tcpdump でSYN到達を確認 |
Connection refused | sshd停止、対象ポートで未待受、接続先ホスト側でREJECT | 接続先で ss -lntp とsshdのサービス状態を確認 |
No route to host | ルーティング不備のほか、環境によってはFirewall拒否が同様に見える | 接続元で ip route get 接続先IP、接続先・経路上のFirewallを確認 |
Permission denied (publickey) | 接続先ユーザーが存在しない、ユーザー名違い、秘密鍵が端末にない・指定されていない・別の鍵を使用、公開鍵未登録、authorized_keysやホームディレクトリの権限・所有者不整合 | ssh -vvv で接続ユーザーと実際に提示している鍵を確認し、接続先のユーザー・公開鍵登録・権限と照合 |
Permission denied, please try again. | パスワード認証の失敗、対象ユーザーの認証方式・アカウント状態の制限 | ユーザー名とsshdの認証設定、認証ログを確認 |
Host key verification failed | known_hostsの既存情報と接続先ホスト鍵が一致しない、または検証できない | 接続先が本当に正しいサーバーかを確認し、ホスト鍵のフィンガープリントを照合 |
REMOTE HOST IDENTIFICATION HAS CHANGED | サーバー再構築・ホスト鍵変更、DNS/IPの向き先変更、または中間者攻撃の可能性 | known_hostsを削除する前に、管理経路で新しいホスト鍵が正当か確認 |
Could not resolve hostname | ホスト名誤り、DNS・search domain・名前解決設定の問題 | getent hosts ホスト名 で名前解決結果を確認 |
原因を切り分ける確認手順
接続先IPと名前解決を確認
getent hosts example-host ssh -G example-host | grep -E '^(hostname|port|user) 'SSH設定ファイルの
HostやPortにより、想定と違うIP・ポート・ユーザーへ接続していないかも確認します。SSHポートへTCP接続できるか確認
nc -vz example-host 22 ssh -vvv user@example-hostタイムアウトか拒否か、SSHの鍵交換まで進んでいるかを確認します。ポートを変更している場合は実際のSSHポートで確認してください。
接続先でsshdが待ち受けているか確認
sudo ss -lntp | grep -E ':(22|SSH_PORT)\b' sudo systemctl status sshd # Debian/Ubuntu系ではサービス名が ssh の場合があります sudo systemctl status sshsshdが起動していても、
ListenAddressやPortにより意図したインターフェース・ポートで待ち受けていない場合があります。sshd設定の構文と実効値を確認
sudo sshd -t sudo sshd -T | grep -E '^(port|listenaddress|passwordauthentication|pubkeyauthentication|permitrootlogin) 'sshd -tは構文確認、sshd -Tは実効設定の確認に使えます。変更前後で確認し、いきなり既存セッションを閉じないようにします。Firewallと許可元CIDRを確認
sudo firewall-cmd --list-all sudo nft list ruleset接続元IPが許可範囲に含まれるか確認します。クラウドや外部Firewallがある場合は、OS側だけでなく経路上のルールも対象です。
サーバー側ログで認証失敗理由を確認
sudo journalctl -u sshd -b --no-pager # 環境により sudo tail -n 100 /var/log/secure sudo tail -n 100 /var/log/auth.logログの場所はディストリビューションや設定で異なります。クライアントの
ssh -vvvと同じ時刻のサーバー側ログを突き合わせます。パケットが接続先まで届いているか確認
sudo tcpdump -ni any 'tcp port 22'SYNが届かないなら途中経路、SYNが届くのに応答しないなら接続先側、TCP接続後に切断されるならsshdや認証側へ調査範囲を移します。
確認結果から次の対応を決める
| 確認結果 | 次に見る場所 |
|---|---|
| 22番ポートへTCP接続できない | Firewall、ACL、ルーティング、SSHポート変更、sshd待受 |
ssにSSHポートがない | sshd起動状態、sshd -t、Port・ListenAddress設定 |
TCP接続後に Permission denied | ユーザー名、認証方式、鍵、authorized_keys、アカウント状態 |
| 公開鍵は提示されるが受理されない | サーバー側ログ、公開鍵一致、所有者・モード、SELinuxコンテキスト |
| ホスト鍵警告が出る | 接続先の正当性とホスト鍵フィンガープリントを確認。確認前にknown_hostsを消さない |
| SSHログインは成功する | 以後の権限・コマンド実行問題はOS側のPermission denied切り分けへ移る |
公開鍵認証で確認するポイント
Permission denied (publickey) の場合は、ネットワーク接続自体は成立しています。まず「正しいユーザーで接続しているか」「クライアントが正しい秘密鍵を使っているか」「その公開鍵が接続先ユーザーに登録されているか」を順に確認します。いきなり鍵を作り直すより、この3点を先に確認したほうが原因を絞りやすくなります。
接続先ユーザーが存在するか確認
getent passwd user id user存在しないユーザー名や、想定と違うユーザー名で接続していると、そのユーザーの
authorized_keysは参照されません。クラウドイメージではec2-user、ubuntuなど既定ユーザーが異なる点にも注意します。秘密鍵ファイルが端末に存在するか確認
ls -l ~/.ssh ls -l ~/.ssh/id_ed25519秘密鍵を削除・移動していたり、端末を変えたことで鍵自体がないケースがあります。ファイル名だけで判断せず、接続時に使う秘密鍵の実体を確認します。
SSHがどの鍵を使っているか確認
ssh -vvv user@example-host ssh -G example-host | grep -E '^(user|hostname|identityfile) ' ssh -vvv -i ~/.ssh/id_ed25519 user@example-host~/.ssh/config、SSH Agent、複数の秘密鍵などにより、想定と違う鍵を提示していることがあります。-iを指定して成功する場合は、通常接続時の鍵選択を見直します。秘密鍵のパーミッションを確認
ls -l ~/.ssh/id_ed25519 chmod 600 ~/.ssh/id_ed25519OpenSSHは、秘密鍵が他ユーザーから読める状態など安全でない権限の場合、その鍵の使用を拒否します。エラーに
UNPROTECTED PRIVATE KEY FILEやPermissions ... are too openが出ていないかも確認します。公開鍵が接続先ユーザーに登録されているか確認
sudo -u user ls -ld /home/user /home/user/.ssh sudo -u user ls -l /home/user/.ssh/authorized_keys sudo -u user cat /home/user/.ssh/authorized_keysクライアント側の秘密鍵に対応する公開鍵が、接続先ユーザーの
authorized_keysに登録されている必要があります。別ユーザーのホームに登録していないかも確認します。接続先の権限・所有者・SELinuxを確認
ls -ld ~ ~/.ssh ls -l ~/.ssh/authorized_keys sudo restorecon -RFv ~/.ssh # SELinux環境で必要な場合~/.sshとauthorized_keysの所有者が対象ユーザーか確認します。書き込み権限が広すぎる場合はStrictModesにより鍵が無視されることがあります。SELinux環境ではコンテキスト不整合も確認します。
-i や IdentityFile で鍵を指定していない」「想定と違う鍵を使用」「秘密鍵の権限が緩い」「公開鍵が未登録」「.ssh / authorized_keys の所有者・権限不整合」です。AuthorizedKeysFileを変更している環境では既定パスだけを前提にせず、sshd -T の実効設定とサーバー側ログを確認してください。
REMOTE HOST IDENTIFICATION HAS CHANGED が出た場合、検索結果どおりに known_hosts を削除するだけでは安全確認になりません。サーバー再構築など正当な変更かを別経路で確認してから更新してください。再発防止
- SSHポート・許可元CIDR・認証方式を設計書や運用手順へ残す
- sshd設定変更前に
sshd -tを実行し、既存SSHセッションを残した状態で新規接続を確認する - Firewall変更時は接続元IPを確認し、不要に広いCIDRを恒久許可しない
- 公開鍵の配布先・有効期限・削除手順を管理し、不要な鍵を残さない
- SSH障害時はクライアントの
ssh -vvvとサーバー側ログを同じ時刻で比較する