インフラ作業支援ラボInfra Support Lab← ガイド一覧← 戻る
トップ > ガイド > トラブル解決 > Permission denied (publickey)
SSHトラブル解決ガイド｜更新日：2026年8月31日

SSH Permission denied (publickey)の原因と確認手順

Permission denied (publickey) が表示される場合、SSHサーバーへの到達とSSHプロトコル開始までは進んでいます。このページでは、「どのユーザーへ、どの鍵で認証しようとしているか」から始め、公開鍵の登録、権限、sshdの実効設定、サーバーログの順に切り分けます。

このページで分かること

  • Permission denied (publickey) が示す失敗段階
  • ssh -G で実際の接続ユーザー・鍵を確認する方法
  • ssh -vvv で鍵が提示されているか確認する方法
  • authorized_keys の登録先・所有者・権限の確認順
  • sshd -T とサーバーログから認証拒否理由を確認する方法

先に結論

最初から chmod 600 をやり直すのではなく、接続ユーザー → 実際に選ばれる秘密鍵 → 対応する公開鍵 → サーバー側の登録先 → 権限・所有者 → sshd実効設定 → ログ の順で確認すると、原因を絞りやすくなります。

Permission denied (publickey) の最短チェック

このエラーでは、まず「権限」ではなく、接続ユーザーと実際に選ばれている鍵が一致しているかを確認します。次の4点で大半の切り分けを始められます。

順番確認コマンド
1実際の接続ユーザー・ホスト・ポート・IdentityFilessh -G example-host
2想定した鍵をクライアントが提示しているかssh -vvv user@example-host
3対象ユーザーの公開鍵登録先と権限authorized_keys / namei -l
4sshdの公開鍵認証設定とログsshd -T / journalctl -u sshd
権限の数値だけを確認したい場合は、authorized_keysと.sshの権限ガイドへ。ここでは認証失敗全体の切り分けを扱い、役割を分けています。
Connection refused / timeout の場合：認証より前の段階で失敗しています。SSH接続できない原因と確認手順を見る →

publickeyエラーが示す段階

Permission denied (publickey) まで進んでいるなら、少なくとも対象ホストのSSHサービスと通信でき、認証フェーズまで到達しています。Connection refused や Connection timed out とは切り分ける場所が違います。

最初の判断：このエラーでは、Firewallや疎通確認を延々と繰り返すより、ユーザー名・鍵・公開鍵登録・sshd認証設定を優先して確認します。

接続ユーザーと使用鍵を確認

~/.ssh/config、コマンドライン、Host/Match設定の影響で、想定と違うユーザーや鍵が選ばれていることがあります。まずクライアント側の実効設定を確認します。

ssh -G example-host | grep -E '^(hostname|user|port|identityfile) '

意図した秘密鍵を明示して再現する場合は、次のように指定します。

ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes user@example-host
注意：「鍵ファイルが存在する」ことと「その接続で鍵が実際に選ばれる」ことは別です。複数鍵やssh-agentを使う環境ほど、実効設定を先に確認してください。

鍵が実際に提示されているか確認

ssh -vvv は接続・認証・設定問題の切り分けに使えます。大量の出力をそのまま共有せず、対象ホスト名・ユーザー名・鍵パスなどの機密情報を確認して扱います。

ssh -vvv user@example-host

確認したいのは、想定したIdentityFileが候補になっているか、公開鍵をサーバーへ提示しているか、提示後に拒否されているかです。

サーバー側の公開鍵登録を確認

接続対象ユーザーのホームディレクトリで、対応する公開鍵が登録されているか確認します。別ユーザーの authorized_keys に登録しても、通常そのユーザーへのログインには使われません。

# 接続先で対象ユーザーを確認 id user getent passwd user # 対象ユーザーの公開鍵ファイルを確認 sudo -u user sh -c 'ls -ld ~/.ssh && ls -l ~/.ssh/authorized_keys'

公開鍵の指紋を比較できる場合は、文字列を目視比較するだけでなく ssh-keygen -lf も利用します。秘密鍵そのものをサーバーやチャットへ貼り付けないでください。

所有者・権限・親ディレクトリを確認

公開鍵認証では authorized_keys の数値権限だけではなく、対象ユーザーの所有物になっているか、ホームや .ssh が他ユーザーから不用意に書き換え可能でないかも重要です。

stat -c '%U:%G %a %n' /home/user /home/user/.ssh /home/user/.ssh/authorized_keys namei -l /home/user/.ssh/authorized_keys

~/.ssh を 700、authorized_keys を 600 とするのは一般的な安全設定例ですが、原因確認前に機械的にchmodするより現状を記録してから修正します。

権限を詳しく確認する場合：700/600の意味、所有者、親ディレクトリ、StrictModes は authorized_keysの権限とchmodガイド に分離しています。

sshdの実効設定を確認

設定ファイルを読むだけでは、includeやMatch条件を見落とすことがあります。可能なら実効設定を確認します。

sudo sshd -T | grep -E '^(pubkeyauthentication|authorizedkeysfile|strictmodes) ' sudo sshd -t

ユーザー・接続元・ホストによる Match 条件がある環境では、実際の接続条件に合わせた評価も検討します。設定変更は既存SSHセッションを残したまま構文確認し、別セッションで成功を確認してから既存接続を閉じます。

サーバーログで拒否理由を確認

クライアント側だけで判断せず、同じ時刻のサーバーログと突き合わせます。サービス名やログ保存先はディストリビューションで異なります。

# systemd環境の例 sudo journalctl -u sshd -b --no-pager sudo journalctl -u ssh -b --no-pager # 必要に応じて時刻を絞る sudo journalctl --since '10 minutes ago' | grep -i ssh
安全上の注意：ログにはユーザー名、IPアドレス、鍵の指紋などが含まれることがあります。外部共有前に確認してください。

結果別の次の対応

確認結果次に見る場所
ユーザー名が違うssh -G や ~/.ssh/config を修正し、正しいユーザーで再確認
違う秘密鍵が選ばれている-i / IdentityFile / IdentitiesOnly を確認
公開鍵が登録されていない対象ユーザーの実際の AuthorizedKeysFile へ正しい公開鍵を安全に登録
所有者・権限に問題がある現状を記録し、対象ユーザーと環境ポリシーを確認して必要最小限の修正
PubkeyAuthentication が無効変更影響と代替接続手段を確保してからsshd設定を修正・構文確認
ログに別の拒否理由があるそのメッセージを起点にユーザー制限、鍵形式、Match条件などを追加確認

権限を変更する前に確認

.ssh や authorized_keys の数値権限を確認するときは、Linux権限計算ツールでrwxとの対応を確認できます。

Linux権限計算を使う
SSH全体を見直す場合：SSHの基本設定と公開鍵認証で接続前の設計を確認できます。通信段階から失敗している場合はSSH接続できない原因と確認手順へ戻ってください。

公式・一次資料