Permission denied (publickey) エラーの原因と対処方法を理解しよう

SSH公開鍵認証を利用していると、多くの管理者が一度は遭遇するエラーがあります。

それが「Permission denied (publickey)」です。

SSH接続時に突然表示されるため戸惑うこともありますが、実際には確認すべきポイントがある程度決まっています。

特にLinuxサーバ構築やクラウド環境の運用では頻繁に発生するトラブルです。

本記事ではPermission denied (publickey) エラーの原因と、効率的な切り分け方法について解説します。

エラー内容を確認する

典型的なエラーです。

Permission denied (publickey).

これはSSHサーバが公開鍵認証に失敗したことを意味します。

ネットワーク接続自体は成功しています。

認証段階で拒否されている状態です。

接続の流れを理解する

公開鍵認証では以下の流れで認証が行われます。

1. SSH接続開始
2. 秘密鍵送信
3. 公開鍵照合
4. 認証成功または失敗

Permission deniedはこの認証段階で発生しています。

まず-vオプションを利用する

最初に実施すべき確認です。

$ ssh -v user@server

詳細なデバッグ情報が表示されます。

原因特定に非常に役立ちます。

さらに詳細を表示する

$ ssh -vvv user@server

実務では-vvvまで利用することが多いです。

認証の流れを細かく確認できます。

原因1 秘密鍵を指定していない

最もよくある原因です。

複数の秘密鍵を利用している環境で発生します。

明示的に指定してみます。

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

これで接続できる場合があります。

原因2 公開鍵が登録されていない

サーバ側のauthorized_keysへ公開鍵が登録されていないケースです。

確認します。

$ cat ~/.ssh/authorized_keys

正しい公開鍵が登録されている必要があります。

原因3 ユーザーを間違えている

クラウド環境でよく発生します。

例えば以下です。

ec2-user
ubuntu
admin
root

OSイメージごとに初期ユーザーが異なります。

原因4 authorized_keysの権限不備

権限が不適切だとSSHは公開鍵を無視します。

推奨権限です。

$ chmod 600 ~/.ssh/authorized_keys

非常によくある原因です。

原因5 .sshディレクトリの権限不備

ディレクトリ権限も重要です。

$ chmod 700 ~/.ssh

緩すぎる権限では認証に失敗します。

原因6 ホームディレクトリの権限不備

ホームディレクトリも確認します。

$ chmod 755 ~

環境によっては影響します。

原因7 所有者が間違っている

ファイル所有者も重要です。

$ chown user:user ~/.ssh
$ chown user:user ~/.ssh/authorized_keys

root所有になっているケースもあります。

原因8 sshd_configの設定ミス

公開鍵認証が無効化されている場合があります。

確認項目です。

PubkeyAuthentication yes

yesになっている必要があります。

原因9 AuthorizedKeysFileの変更

公開鍵ファイルの場所が変更されていることがあります。

確認します。

AuthorizedKeysFile .ssh/authorized_keys

通常はデフォルト設定です。

原因10 秘密鍵の権限不備

クライアント側の秘密鍵も確認します。

$ chmod 600 ~/.ssh/id_ed25519

権限が広いと利用を拒否されます。

原因11 ssh-agentの問題

ssh-agent利用時に発生することがあります。

登録済み鍵を確認します。

$ ssh-add -l

必要な鍵が登録されているか確認しましょう。

原因12 ED25519未対応環境

古いSSHサーバではED25519未対応の場合があります。

サーバ側のOpenSSHバージョンを確認します。

# ssh -V

原因13 RSAアルゴリズムの問題

最近のOpenSSHでは古いRSA方式が無効化されています。

古いサーバとの接続時に発生することがあります。

原因14 SELinuxによる制限

SELinuxが原因で公開鍵を読み取れない場合があります。

確認します。

# getenforce

後の記事で詳しく解説します。

原因15 NFSホームディレクトリ

NFS環境では権限やマウントオプションが影響することがあります。

企業環境で発生することがあります。

サーバログを確認する

最も重要な確認ポイントです。

# journalctl -u sshd

または
# tail -f /var/log/secure

認証失敗理由が表示されます。

典型的なログ例

Authentication refused:
bad ownership or modes

権限問題であることが分かります。

SSH設定の構文確認

設定変更後は必ず確認します。

# sshd -t

構文エラーを発見できます。

実務での切り分け手順

以下の順番がおすすめです。

1. ssh -vvvで確認
2. authorized_keys確認
3. 権限確認
4. 所有者確認
5. sshd_config確認
6. journalctl確認

ほとんどの問題はこの手順で解決できます。

AWSでよくある事例

EC2では秘密鍵の取り違えが頻発します。

またユーザー名間違いも多いです。

• ec2-user
• ubuntu
• admin

AMIごとに確認しましょう。

Azureでよくある事例

作成時のユーザー名を忘れてしまうケースがあります。

VM作成情報を確認しましょう。

実務で最も多い原因

経験上は以下が多いです。

• authorized_keys未登録
• 権限不備
• 所有者不備
• 秘密鍵間違い
• ユーザー名間違い

まずはここを確認しましょう。

まとめ

Permission denied (publickey) はSSH公開鍵認証で最もよく遭遇するエラーの一つです。

しかし原因はある程度パターン化されており、authorized_keys、権限、所有者、SSH設定を順番に確認することで効率的に解決できます。

特にssh -vvvとjournalctl -u sshdは強力な調査手段なので、実務では必ず活用できるようになりましょう。

トラブル発生時は慌てずに切り分けを行うことが重要です。

関連記事:

authorized_keysの役割とは？SSH公開鍵認証の仕組みと設定方法 LinuxからSSH接続する方法｜基本操作から実務で役立つ接続方法まで解説 ssh-agentとは？秘密鍵のパスフレーズ入力を省略する仕組みを解説 SSH秘密鍵の安全な管理方法｜漏洩を防ぐベストプラクティス