SSH で接続できないときのチェックリスト（known_hosts / 鍵 / Permission denied）

2025-12-15 読了時間: 約12分 難易度: 中級

この記事で解決できること

• SSH で接続できないときに、原因を順番に切り分けできます
• Permission denied (publickey) や Host key verification failed の対処が分かります
• 鍵ファイル・権限・known_hosts・sshd 設定の「新人が詰まりやすい箇所」を避けられます

1. まず接続コマンドを明確にする（基本形）

結論: ssh接続はuser/host/portの3点を明確にしてから-vで詳細ログを出して原因を絞り込むのが基本形。

$ ssh user@server.example.com

ポートを指定する場合（例: 2222）:

$ ssh -p 2222 user@server.example.com

鍵を指定する場合:

$ ssh -i ~/.ssh/id_ed25519 user@server.example.com

2. "まずこれ"で原因の手がかりを出す（-v）

結論: ssh -vで詳細ログを出すと認証・ネットワーク・known_hostsのどの段階で失敗しているかが判明する。

エラーの切り分けは、詳細ログを出すのが最短です。

$ ssh -v user@server.example.com

さらに詳細（必要なときだけ）:

$ ssh -vv user@server.example.com

ケースA: Permission denied (publickey)

結論: 鍵ファイルの存在・権限（秘密鍵600・.ssh 700）・authorized_keysへの登録を順番に確認して鍵認証を通す。

意味: サーバは到達しているが、鍵認証で拒否されている。

確認1: 鍵ファイルが存在するか

$ ls -la ~/.ssh

確認2: 鍵ファイルの権限（これが悪いと鍵が使えない）

一般的な目安:

• 秘密鍵: 600
• .ssh ディレクトリ: 700

$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/id_ed25519

確認3: どの鍵を使っているか明示する

$ ssh -i ~/.ssh/id_ed25519 user@server.example.com

確認4: サーバ側に公開鍵が登録されているか

サーバ側で確認（ログインできる別経路がある場合や、コンソールから）:

$ ls -la /home/user/.ssh
$ ls -la /home/user/.ssh/authorized_keys

権限の目安:

$ chmod 700 /home/user/.ssh
$ chmod 600 /home/user/.ssh/authorized_keys
$ chown -R user:user /home/user/.ssh

ケースB: Host key verification failed

結論: サーバ再構築やIP再利用後のknown_hosts不一致はssh-keygen -Rで該当エントリを削除して再接続する。

意味: "そのサーバは本当に前に接続したサーバと同じか？"の検証で止まっています。サーバ再構築や IP 再利用でよく起きます。

対処（該当ホストの known_hosts エントリを削除）:

$ ssh-keygen -R server.example.com

IP で接続している場合:

$ ssh-keygen -R 203.0.113.10

その後、再接続して指紋を確認のうえ受け入れます。

ケースC: Connection timed out

結論: timed outはネットワーク的に到達できていないためDNS解決とポート疎通をncで確認しFWやSGを疑う。

意味: ネットワーク的に到達できていない（FW/SG/ルーティング/ポート違いの可能性）。

確認1: DNS が引けているか

$ dig server.example.com +short

確認2: ポートが開いているか（22以外も）

nc がある場合:

$ nc -vz server.example.com 22

ポートが違う場合:

$ nc -vz server.example.com 2222

ケースD: Connection refused

結論: Connection refusedはsshdが起動していないかポートが違うためsystemctl status sshとss -lntpで確認する。

意味: サーバに到達しているが、SSH がそのポートで待ち受けていない可能性が高い。

確認1: sshd サービスが動いているか

Ubuntu では service 名は ssh のことが多いです。

$ sudo systemctl status ssh

起動:

$ sudo systemctl start ssh

自動起動:

$ sudo systemctl enable ssh

確認2: 待受ポートを確認

$ sudo ss -lntp | grep ssh

4. サーバ側ログで原因を確定する（journalctl）

結論: journalctl -u ssh -n 200でサーバ側ログを確認すると鍵不一致やユーザー違いなど認証失敗の理由が特定できる。

サーバ側でログを見ると、ほぼ確定できます。

$ sudo journalctl -u ssh -n 200

直近だけ追う:

$ sudo journalctl -u ssh -f

Permission denied の理由（鍵が違う/ユーザー違い等）がログに出ることがあります。