DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ

SSHの「Permission Denied (publickey)」エラーのトラブルシューティング

SSH接続時に「Permission Denied (publickey)」エラーが発生した場合の包括的な解決ガイドです。SSHキーペアの確認方法、クライアントとサーバー両方のファイルパーミッションの診断、authorized_keysファイルの正しい設定方法を詳しく解説します。実践的な例とステップバイステップの手順で、リモートシステムへの安全なアクセスを回復できます。

SSHの「Permission Denied (publickey)」エラーのトラブルシューティング

Permission denied (publickey) は、サーバーには到達できたものの、指定したユーザーに対する公開鍵認証の試行がすべて拒否されたことを意味します。これにより問題が絞り込まれます。ルーティング、DNS、SSHポートが開いているかどうかのデバッグは不要です。デバッグすべきは、ユーザー名、クライアントが提示した秘密鍵、サーバーに保存された公開鍵、そしてログインを許可するかどうかを決定するサーバールールです。

最も迅速な有用なコマンドは次のとおりです：

ssh -vvv user@your_server_ip

Authenticating to ... as 'user' を探し、次に Offering public key を探します。期待する鍵が提示されない場合はクライアントを修正します。期待する鍵が提示されて拒否された場合は、サーバー側の authorized_keys、所有権、パーミッション、またはSSHデーモンポリシーを修正します。

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

「Permission Denied (publickey)」エラーは、いくつかの設定の問題に起因する可能性があります。根本原因を特定するには、以下のコンポーネントを体系的に確認することがよくあります。

  • ファイルパーミッションの誤り： SSHはセキュリティ上の理由から、ファイルとディレクトリのパーミッションに非常に敏感です。ローカルの ~/.ssh ディレクトリ、秘密鍵ファイル、またはサーバー側の ~/.ssh ディレクトリと authorized_keys ファイルのパーミッションが正しくないと、認証が妨げられる可能性があります。
  • authorized_keys エントリの欠落または誤り： サーバーの authorized_keys ファイルには、ログインしようとしているユーザーの正しい公開鍵が含まれている必要があります。鍵が欠落している、形式が正しくない、または間違ったユーザーに関連付けられている場合、認証は失敗します。
  • 鍵ペアの関連付けの誤り： SSHクライアントが間違った秘密鍵を提示しているか、サーバーが authorized_keys ファイルに対応する公開鍵を持っていない可能性があります。
  • SSHエージェントの問題： SSHエージェントを使用している場合、秘密鍵が正しくロードされていないか、設定が間違っている可能性があります。
  • サーバー側のSSH設定： この特定のエラーではあまり一般的ではありませんが、サーバーのSSHデーモン設定（sshd_config）に公開鍵認証に関する特定の制限がある場合があります。

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

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

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

最初に確認するのはローカルのSSH設定です。秘密鍵がアクセス可能で、正しいパーミッションを持っていることを確認します。

秘密鍵の存在確認

秘密鍵は通常 ~/.ssh/id_ed25519 または ~/.ssh/id_rsa にありますが、多くのチームはプロジェクト固有の名前を使用します。鍵を一覧表示します：

ls -la ~/.ssh

秘密鍵を authorized_keys にアップロードしたり貼り付けたりしないでください。サーバーが必要とするのは .pub ファイルの内容であり、秘密鍵ではありません。

ローカルファイルのパーミッションを確認する

~/.ssh ディレクトリと秘密鍵ファイルは、不正アクセスを防ぐために制限的なパーミッションを持つ必要があります。

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

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

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

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

特定の鍵をテストする場合は、強制的に指定します：

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_prod user@your_server_ip

これにより、エージェントが最初に関係のない鍵の長いリストを提示するのを防ぎます。

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

また、所有権も確認します。.ssh ディレクトリと authorized_keys ファイルは通常、ログインするアカウントに属している必要があります：

chown -R youruser:youruser ~/.ssh
ls -ld ~ ~/.ssh ~/.ssh/authorized_keys

sshd_config で StrictModes が有効になっている場合、ホームディレクトリや .ssh パスが間違ったユーザーによって書き込み可能であると、OpenSSH が鍵を拒否する可能性があります。

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 ファイルのエントリと注意深く比較します。1文字のタイプミスや欠落でも認証は失敗します。

より明確に比較するには、使用しようとしている秘密鍵から派生した公開鍵を表示します：

ssh-keygen -y -f ~/.ssh/id_ed25519_prod

その出力は、リモートユーザーの authorized_keys の1行と一致する必要があります。

ヒント：サーバーにパスワードアクセスできる場合、公開鍵を追加する簡単な方法は 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 オプションでIDファイル（秘密鍵）を指定できます：

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
  IdentitiesOnly yes

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

ssh your_server_alias

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

SSHエージェントに依存して鍵を管理している場合、エージェントが実行中で鍵がロードされていることを確認します。

エージェントが実行中か確認する
echo "$SSH_AUTH_SOCK"

これがパスを出力する場合、エージェントは実行中である可能性があります。空の場合は、起動する必要があるかもしれません。

エージェントに鍵を追加する

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

ssh-add ~/.ssh/id_rsa

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

ssh-add -l に関係のない鍵が多数表示され、数回の試行後にサーバーが切断される場合は、エージェントから古い鍵を削除するか、そのホストに IdentitiesOnly yes を使用します。

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 の確認（上級者向け）

/etc/ssh/sshd_config および /etc/ssh/sshd_config.d/ 内のファイルを確認します。公開鍵認証が有効になっていることを確認します：

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

次に、ファイルの下部近くにある Match ブロックを探します。後続の Match User、Match Group、または Match Address ブロックは、テストしているアカウントに対して以前の設定を上書きする可能性があります。

変更後、リロードする前に構文を検証します：

sudo sshd -t
sudo systemctl reload sshd

一部のシステムでは、サービス名として sshd の代わりに ssh を使用します。

信頼性の高いトラブルシューティングの順序

推測を避けるために詳細出力を使用します。まずユーザー名を確認します。次に、クライアントが期待する秘密鍵を提示していることを確認します。次に、一致する公開鍵がターゲットユーザーの authorized_keys にあることを確認します。その後、所有権とパーミッションを確認します。これらがクリーンになった後にのみ、sshd_config、Match ブロック、SELinuxコンテキスト、またはアカウント制限に時間を費やすべきです。

この順序により、ランダムな変更を行うことなく、ほとんどの Permission denied (publickey) ケースが解決され、緊急のログインを1つ取得するためだけにSSHセキュリティを弱体化させることを防ぎます。