SSH「Permission Denied」エラーと接続問題の一般的なトラブルシューティング

SSHのPermission deniedエラーは、通常、サーバーには到達できたものの、認証が拒否されたことを意味します。これはConnection timed out、Connection refused、No route to hostとは異なります。これらすべてを「SSHが壊れている」と扱うと時間の無駄になるため、まず認証失敗とネットワーク障害を区別しましょう。

失敗しているコマンドを詳細ログ付きで実行します：

ssh -vvv user@remote_host

探すべき明確な手がかりは、クライアントが使用したユーザー名、提示した鍵ファイル、サーバーが鍵を受け入れたかどうか、そして残っている認証方法です。以下の修正のほとんどは、これらの手がかりをサーバー側の状態と照合することから得られます。

SSH認証フローの理解

接続を試みると、サーバーは設定で有効になっている認証方法のみを許可します。典型的なサーバーは最初に公開鍵認証を試み、ポリシーに応じてその後パスワード認証を許可する場合があります：

公開鍵認証： クライアントが公開鍵を提示し、サーバーは対応する秘密鍵が有効で、許可された鍵（authorized_keysファイル）と一致するか確認します。
パスワード認証： 鍵認証が失敗するか無効になっている場合、サーバーはパスワードを要求します。

Permission deniedを受け取った場合、TCP接続は成功しています。サーバーがそのユーザーに対して提示された資格情報を受け入れなかっただけです。

接続問題の診断：詳細モードの威力

SSH問題を診断する最も効果的なツールは、クライアントを詳細モードで実行することです。-v、-vv、または-vvvフラグを追加することで、クライアントはネゴシエーションプロセスに関する詳細なデバッグ情報を出力します。

詳細フラグの使用

次のコマンド構造を使用します：

ssh -vvv user@remote_host

出力で確認すべき点：

ユーザー名： Authenticating to ... as 'user'を探します。間違ったLinuxユーザー名は、見落としやすいミスの一つです。
提示された鍵： Offering public keyを探します。期待する鍵が表示されない場合、クライアント設定を修正します。
サーバーの応答： 提示されたすべての鍵の後にAuthentications that can continueが続く場合、サーバーはそれらの鍵を拒否しています。
認証方法： publickeyがリストにない場合、サーバーはそのアカウントまたはホストブロックに対して鍵認証を許可していない可能性があります。

`Permission denied (publickey)`の解決

このエラーは、サーバーが提供された公開鍵の資格情報を拒否したことを明示的に示しています。修正は通常、権限または鍵のペアリングにあります。

1. 鍵ファイルの権限を確認する（クライアント側）

セキュリティのため、SSHクライアントは秘密鍵ファイル（例：~/.ssh/id_rsa）の権限に非常に厳格です。これらのファイルが開かれすぎていると、クライアントはそれらを使用しません。

秘密鍵が自分だけ読み取り可能であることを確認します：

chmod 600 ~/.ssh/id_rsa

2. 鍵の存在と正しい鍵の使用を確認する

特に非標準の鍵や複数の鍵ペアを使用する場合、正しいIDファイルで接続していることを確認します。

-iフラグを使用して正しい秘密鍵を指定します：

ssh -i /path/to/your/specific_private_key user@remote_host

エージェントに多くの鍵がロードされている場合、このテストのためにIdentitiesOnly=yesを追加します：

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

3. サーバー側の権限と所有権

これは鍵認証失敗の最も一般的な原因です。SSHは、ログインしようとしているユーザーのサーバー上のディレクトリとファイルの権限を厳格に強制します。

サーバー上のパス	必要な権限	所有者
`~/.ssh`ディレクトリ	`700` (rwx------)	ユーザー
`~/.ssh/authorized_keys`ファイル	`600` (rw-------)	ユーザー

コンソール、クラウドシリアルコンソール、パスワード認証、または別の管理者アカウントを介してログインし、対象ユーザーとして、または正しいパスで次のコマンドを実行します：

# ディレクトリの権限を設定
chmod 700 ~/.ssh

# authorized_keysの権限を設定
chmod 600 ~/.ssh/authorized_keys

# 所有権を確認（'myuser'を実際のユーザー名に置き換え）
chown -R myuser:myuser ~/.ssh

ユーザーのホームディレクトリがグループまたはその他によって書き込み可能な場合、StrictModesが有効になっているとOpenSSHが鍵を拒否する可能性があります。以下で確認します：

ls -ld ~ ~/.ssh ~/.ssh/authorized_keys

通常のユーザーホームの場合、755以上で問題ありません。

4. 鍵が実際に追加されていることを確認する

クライアントの公開鍵がサーバーの~/.ssh/authorized_keysファイルに貼り付けられたものと一致することを確認します。文字の欠落、行の折り返し、または秘密鍵のコピーは認証失敗の原因になります。

鍵を追加する際、パスワードアクセスがまだ利用可能な場合はssh-copy-idを使用します：

ssh-copy-id user@remote_host

設定ファイルの問題のトラブルシューティング（`sshd_config`）

鍵と権限が正しい場合、問題は通常、サーバーのSSHデーモン設定ファイル（通常は/etc/ssh/sshd_config）にあります。

1. 認証方法を確認する

公開鍵認証が明示的に許可されていることを確認します。

設定の確認： 次の行を探し、コメントアウトされておらず（#）、正しく設定されていることを確認します：

PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

また、ファイルの下部近くにあるMatchブロックも確認します。グローバル設定で公開鍵が許可されていても、後続のMatch User、Match Group、またはMatch Addressブロックで、テストしているログインに対して無効になっている場合があります。

2. パスワード認証の状態

一時的にパスワードログインに依存している場合、それが有効になっていることを確認します。noに設定されている場合、必ず鍵を使用する必要があります。

PasswordAuthentication yes

3. PermitRootLogin

rootとしてログインしようとしている場合、これが許可されていることを確認します。ベストプラクティスは通常のユーザーとしてログインしsudoを使用することですが、トラブルシューティングのためにこの設定を確認できます：

PermitRootLogin prohibit-password

ルートログインの場合、多くのシステムはデフォルトで鍵のみのルートアクセスにするか、ルートログインを完全に無効にします。通常のユーザーとsudoを推奨します。SSHデーモンの設定を変更する必要がある場合は、リロード前に構文を検証します：

sudo sshd -t
sudo systemctl reload sshd  # 一部のシステムでは：sudo systemctl reload ssh

その他の一般的な接続エラー

鍵の問題が主ですが、他のエラーがアクセスを妨げる可能性があります：

A. Connection Timed Out

これは通常、クライアントがサーバーにまったく到達できなかったことを意味し、認証の問題ではなくネットワークの問題を示します。

考えられる原因：

サーバーがダウンしているか到達不能です。
ファイアウォール（ローカルまたはネットワーク）がポート22（またはカスタムSSHポート）での接続をブロックしています。
誤ったIPアドレスまたはホスト名。

基本的な到達可能性のヒントとしてpingを使用し、SSHポートを確認するためにncを使用します：

nc -vz remote_host 22

B. No Route to Host

タイムアウトと同様に、これはネットワークインフラストラクチャの問題です。クライアントはサーバーのIPアドレスへのパスを見つけられません。ルーティングテーブル、VPNの状態を確認するか、リモートサーバーに有効なネットワークインターフェースがアクティブであることを確認します。

C. Server Refused Our Key

詳細出力でサーバーが鍵を積極的に拒否しているが、authorized_keysファイルを確認した場合、サーバーのSELinuxまたはAppArmorセキュリティコンテキストを確認します。これらのセキュリティモジュールはファイル権限を上書きし、コンテキストが正しくない場合にSSHアクセスをブロックする可能性があります。

通常効果的な実践的な順序

最初にユーザー名を確認します。次に、ssh -o IdentitiesOnly=yes -i ...で期待する鍵を強制します。クライアントが正しい鍵を提示し、サーバーがそれを拒否した場合、サーバー上のauthorized_keys、所有権、および権限を検査します。鍵が提示されない場合、ローカルの~/.ssh/config、エージェント、または鍵のパスを修正します。接続が認証に到達しない場合、鍵ファイルを変更する代わりにネットワークのトラブルシューティングに切り替えます。