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

Secure Shell（SSH）は、リモートサーバー管理の基盤であり、リモートシステムへのアクセスと制御のための暗号化された通信を提供します。SSHは信頼性が高いですが、特に鍵認証の設定時には、フラストレーションのたまる接続障害が発生することがあります。最も一般的な原因は、厄介な Permission denied エラーです。

この包括的なガイドでは、最も頻繁に発生するSSHエラーの診断と解決方法を説明します。特に、Permission denied (publickey) の背後にある根本原因を理解することに焦点を当て、ファイルパーミッション、不正な設定、クライアント/サーバー設定の不一致に関連する一般的な落とし穴に対処します。これらのトラブルシューティング手順を習得することで、リモートインフラストラクチャへの安全で信頼性の高いアクセスを確保できます。

SSH認証フローの理解

トラブルシューティングの前に、SSHがユーザーをどのように認証するかを理解することが重要です。接続を試みると、サーバーは通常、設定に応じて次の順序で認証情報をチェックします。

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

Permission denied というエラーが表示される場合、それはほぼ常に、サーバーがステップ1または2であなたの認証情報を拒否したことを意味します。

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

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

詳細フラグの使用

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

ssh -vvv user@remote_host

出力で確認すること:

鍵交換: クライアントが試行した認証方法を示す行（例: Offering RSA key: /path/to/id_rsa）を探します。
サーバーの応答: サーバーの拒否メッセージに細心の注意を払います。出力にサーバーが鍵をチェックしているが一致しないというメッセージが表示される場合、問題はサーバー側の鍵の設定またはパーミッションにある可能性が高いです。
パスワードプロンプト: 出力が鍵チェックをスキップしてすぐにパスワードを要求する場合、サーバーで鍵認証が無効になっている可能性があります。

`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

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

警告: ユーザーのホームディレクトリ（~/）のパーミッションが広すぎる場合（例: グループまたは他のユーザーが書き込み可能）、セキュリティ上の理由からSSHも失敗する可能性があります。問題が続く場合は、~/ に対して 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

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

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

PasswordAuthentication yes

3. PermitRootLogin

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

PermitRootLogin yes

重要なステップ: /etc/ssh/sshd_config のいずれかの変更後、変更を有効にするにはSSHサービスを再起動する必要があります。
bash sudo systemctl restart sshd # または service ssh restart

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

鍵の問題が主ですが、他のエラーがアクセスをブロックすることがあります。

A. Connection Timed Out

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

考えられる原因:
* サーバーがダウンしているか、到達不能である。
* ファイアウォール（ローカルまたはネットワーク）がポート22（またはカスタムSSHポート）での接続をブロックしている。
* IPアドレスまたはホスト名が間違っている。

トラブルシューティング: 基本的な接続を確認するには ping を使用し、ポートが開いているかを確認するには telnet または nc (netcat) を使用します。

# ポート22が到達可能か確認
telnet remote_host 22

B. No Route to Host

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

C. Server Refused Our Key

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

ベストプラクティスの概要

常に詳細モード（-vvv）を使用して診断します。
クライアント鍵のセキュリティ: 秘密鍵が 600（chmod 600）に設定されていることを確認します。
サーバーファイルの整合性: ~/.ssh が 700、authorized_keys が 600 であることを確認します。
デーモンの再起動: /etc/ssh/sshd_config を変更した後は、必ず sshd を再起動します。
鍵の展開を自動化するために、可能な限り ssh-copy-id を使用します。