SSHの「Permission Denied Publickey」問題のトラブルシューティング

SSH 'Permission Denied (publickey)' の問題解決

SSH経由でリモートサーバーに接続しようとした際、「Permission Denied (publickey)」エラーに遭遇すると、作業が妨げられ苛立ちを感じることがあります。このエラーは、公開鍵を使用して認証できなかったために、サーバーが接続を拒否したことを具体的に示しています。パスワードベースの認証とは異なり、公開鍵暗号方式は、ローカルマシンに秘密に保管される秘密鍵と、サーバーに配置される公開鍵のペアに依存しています。このガイドでは、このエラーの一般的な原因を順を追って説明し、それらを診断および解決するための詳細な手順を提供することで、安全かつシームレスなSSHアクセスを保証します。

SSH公開鍵認証プロセスを理解することは、効果的なトラブルシューティングに不可欠です。接続を試行すると、SSHクライアントは公開鍵をサーバーに提示します。サーバーは、この公開鍵があなたのユーザーアカウントに対して認可されているかを確認します。認可されている場合、サーバーはあなたの公開鍵でチャレンジを暗号化して返送します。対応する秘密鍵を持っているあなたのクライアントは、そのチャレンジを復号し、応答をサーバーに返送します。応答が正しければ、認証は成功します。「Permission Denied (publickey)」エラーは、このやり取りのどこかの時点で失敗したことを意味します。

「Permission Denied (publickey)」の一般的な原因

「Permission Denied (publickey)」エラーは、いくつかの設定上の問題から生じる可能性があります。根本原因を特定するには、通常、次のコンポーネントを体系的に確認する必要があります。

ファイルパーミッションの誤り: セキュリティ上の理由から、SSHはファイルやディレクトリのパーミッションに非常に敏感です。ローカルの~/.sshディレクトリ、秘密鍵ファイル、またはサーバー側の~/.sshディレクトリやauthorized_keysファイルのパーミッションが正しくないと、認証が妨げられる可能性があります。
Missing or Incorrect authorized_keys Entry: サーバーのauthorized_keysファイルには、ログインしようとしているユーザーに対応する正しい公開鍵が含まれている必要があります。鍵がない、形式が崩れている、または間違ったユーザーに関連付けられている場合、認証は失敗します。
鍵ペアの関連付けの誤り: SSHクライアントが間違った秘密鍵を提供しているか、サーバーのauthorized_keysファイルに対応する公開鍵がリストされていない可能性があります。
SSH Agent Issues: SSHエージェントを使用している場合、秘密鍵が適切にロードされていないか、設定が間違っている可能性があります。
サーバー側のSSH設定: この特定のエラーの原因としては稀ですが、サーバーのSSHデーモン設定 (sshd_config) に公開鍵認証に関する特定の制限がある可能性があります。

ステップバイステップのトラブルシューティングガイド

これらの問題を診断し、修正するための実際的な手順を見ていきましょう。

1. ローカルの秘密鍵とパーミッションの確認

最初にチェックすべきは、ローカルのSSH設定です。秘密鍵にアクセス可能であり、正しいパーミッションが設定されていることを確認してください。

秘密鍵の存在の確認

秘密鍵は通常、~/.ssh/id_rsa (または id_ed25519、id_dsa など) にあります。

ローカルファイルパーミッションの検証

不正アクセスを防ぐために、~/.sshディレクトリおよび秘密鍵ファイルには制限的なパーミッションが設定されている必要があります。

~/.ssh ディレクトリ: 700 (drwx------) である必要があります。
秘密鍵ファイル (例: id_rsa): 600 (-rw-------) である必要があります。

chmodコマンドを使用して、正しいパーミッションを設定します。

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa

*ヒント: 異なる鍵名を使用している場合は、id_rsaを実際の秘密鍵ファイル名に置き換えてください。

2. サーバー側の`authorized_keys`設定の確認

これは最も一般的な原因であることが多いです。サーバーには、認証しようとしているユーザーに対して、あなたの公開鍵が正しくリストされている必要があります。

サーバーへのアクセス (可能な場合)

別の方法（例：パスワード認証、別のユーザーアカウント、またはコンソール）でサーバーにアクセスできる場合は、ログインしてauthorized_keysファイルを確認します。

`authorized_keys`ファイルの場所の確認

authorized_keysファイルは通常、ログインしようとしているユーザーのホームディレクトリ内の~/.ssh/authorized_keysにあります。

サーバー側ファイルパーミッションの検証

クライアント側と同様に、サーバー側のパーミッションも重要です。

サーバー上の~/.sshディレクトリ: 700 (drwx------) である必要があります。
サーバー上のauthorized_keysファイル: 600 (-rw-------) である必要があります。

サーバーでこれらのパーミッションが正しく設定されていることを確認してください。

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

`authorized_keys`の内容の検証

テキストエディタ（例：nano、vim）を使用して~/.ssh/authorized_keysファイルを開きます。各公開鍵は1行に記述されている必要があります。使用する予定の公開鍵が存在し、正しくフォーマットされていることを確認してください。鍵はssh-rsa、ssh-ed25519などで始まり、その後に長い文字列が続き、オプションでコメントが付いている場合があります。

authorized_keysエントリの例:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQD... your_public_key_string user@hostname

*重要: 秘密鍵をauthorized_keysに追加しないでください。ここには公開鍵のみを含める必要があります。

3. 正しい公開鍵が追加されていることを確認

間違った公開鍵がコピーされたか、サーバー上の公開鍵がローカルの秘密鍵と一致していない可能性があります。

ローカルの公開鍵の取得

公開鍵は秘密鍵と対になるものです。ssh-keygenコマンドを使用して表示できます。

cat ~/.ssh/id_rsa.pub

このコマンドはあなたの公開鍵を出力します。この出力と、サーバーの~/.ssh/authorized_keysファイル内のエントリを慎重に比較してください。タイプミスや文字の欠落が一つでもあれば、認証は失敗します。

*ヒント: パスワードアクセスが可能な場合、公開鍵をすばやく追加する簡単な方法はssh-copy-idを使用することです。

ssh-copy-id user@your_server_ip

このコマンドは、デフォルトの公開鍵 (~/.ssh/id_rsa.pub) をリモートサーバーの~/.ssh/authorized_keysファイルに自動的に追加し、正しいパーミッションを設定します。

4. 正しい秘密鍵を指定する (デフォルトでない場合)

デフォルト以外の秘密鍵（例：~/.ssh/my_other_key）を使用している場合は、SSHクライアントに使用する鍵を伝える必要があります。

`-i`フラグの使用

-iオプションを使用して、アイデンティティファイル（秘密鍵）を指定できます。

ssh -i ~/.ssh/my_other_key user@your_server_ip

`~/.ssh/config`の設定

利便性のために、特定のホストに対して常に特定の鍵を使用するようにSSHクライアントを設定できます。

ローカルマシン上の~/.ssh/configファイルを作成または編集し、次のようなエントリを追加します。

Host your_server_alias
  HostName your_server_ip_or_domain
  User your_username
  IdentityFile ~/.ssh/my_other_key

その後、次のように簡単接続できます。

ssh your_server_alias

5. SSHエージェントの状態を確認

鍵の管理にSSHエージェントを使用している場合は、それが実行されており、鍵がロードされていることを確認してください。

エージェントが実行されているか確認

echo "$SSH_AUTH_SOCK"

これがパスを出力する場合、エージェントは実行されている可能性が高いです。空の場合、開始する必要があるかもしれません。

エージェントへの鍵の追加

鍵がロードされていない場合は、追加します。

ssh-add ~/.ssh/id_rsa

パスフレーズを求められたら入力します。ssh-add -lでどの鍵が追加されているかを確認できます。

6. 詳細モードでのデバッグ

SSHには詳細モード (-v、-vv、またはさらに詳細な -vvv) があり、認証プロセスがどこで失敗しているかについて非常に貴重な手がかりを提供できます。

ssh -vvv user@your_server_ip

鍵認証、鍵の提示、およびサーバー応答に関連するメッセージについて出力を精査します。これにより、問題が直接特定されることがよくあります。

公開鍵の失敗を示す詳細出力の例 (抜粋):

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/id_rsa
debug1: read PEM private key file /home/user/.ssh/id_rsa
debug1: failed to use sshkey: /home/user/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password

この出力は、クライアントがid_rsaの使用を試みたが失敗し、その後他の方法に移行したことを示している可能性があります。

7. サーバー側`sshd_config`の確認 (上級)

publickey固有のエラー（通常、他のエラーが表示されるはずです）の原因としては稀ですが、サーバーのSSHデーモン設定ファイル (/etc/ssh/sshd_config) を確認する価値があります。PubkeyAuthentication yesがコメントアウトされておらず、yesに設定されていることを確認してください。変更を加えた後、SSHサービスをリロードまたは再起動する必要があります（例：sudo systemctl reload sshd または sudo systemctl restart sshd）。

まとめとベストプラクティス

SSH「Permission Denied (publickey)」エラーのトラブルシューティングには、クライアントとサーバーの両方の設定を系統的にチェックすることが含まれます。最も頻繁な原因は、~/.sshおよびauthorized_keysファイルのファイルパーミッションの誤り、およびサーバー上の公開鍵とクライアント上の秘密鍵の不一致に関連しています。

重要なポイント:

パーミッションは最重要: クライアントとサーバーの両方で、常に~/.sshが700、秘密鍵/authorized_keysが600であることを確認してください。
公開鍵の正確性: 正確な公開鍵がサーバーのauthorized_keysファイルに存在することを再確認してください。
ssh-copy-idの使用: 可能な限り、これが公開鍵認証を設定する最も安全で簡単な方法です。
詳細モード: ssh -vvvを利用して、詳細な診断出力を取得してください。

これらの手順に従うことで、ほとんどの「Permission Denied (publickey)」の問題を診断および解決し、サーバーへの安全なリモートアクセスを回復できるはずです。