WinSCPやターミナルからLinuxサーバーへSSH公開鍵認証でアクセスした際、突然発生するおなじみのエラー。
Permission denied (publickey).「秘密鍵の指定は合っているはずなのに繋がらない」「さっきまでログインできていたのになぜか拒否される」という場合、原因の9割はSSHディレクトリや認証キーファイルのパーミッション（権限）設定の不備、または所有者（所有グループ）の不整合にあります。
OpenSSHデーモン（sshd）には「セキュリティ上のリスクがある緩い権限設定を検知すると、鍵が合致していても接続を自動的に拒絶する（StrictModes）」という強力な防御機構が備わっているためです。
本記事では、公開鍵認証で接続拒否されるパーミッションの厳格ルールと、サーバー側ログを用いた最短トラブルシューティング手順を解説します。
1. 最重要：SSHが要求する厳格なパーミッションルール
SSHサーバーは、第三者による鍵の改ざんや盗難を防ぐため、権限が「グループや他人に読み書き可能」になっていると認証を無効化します。
正常に接続するために必須となるパーミッション設定は以下の通りです。
| 対象ディレクトリ/ファイル | 推奨パーミッション | 意味 |
|---|---|---|
ホームディレクトリ（~ または /home/username） | 755（drwxr-xr-x）または 700 | 所有者以外に書き込み権限（w）がないこと |
.ssh ディレクトリ（~/.ssh） | 700（drwx------） | 所有者のみ読み書き・実行可能 |
authorized_keys（~/.ssh/authorized_keys） | 600（-rw-------） | 所有者のみ読み書き可能 |
秘密鍵（id_rsa / id_ed25519 等） | 600（-rw-------） | ローカル側の鍵。他人に読み取り権限がないこと |
見落としがちな罠：ホームディレクトリの権限
.ssh や authorized_keys のパーミッションを正しく設定していても、親ディレクトリである /home/username 自体にグループ書き込み権限（例: 775 や 777）が付いていると、StrictModesによって即座に接続が弾かれます。
2. 権限の一括修復コマンド
もしパーミッションの崩れが疑われる場合、対象ユーザー（例: ubuntu ユーザー）でログインできる環境やコンソールから、以下のコマンドを実行して一括リセットします。
# 所有者を対象ユーザーに確実に揃える
sudo chown -R ubuntu:ubuntu /home/ubuntu/.ssh
# ホームディレクトリの他者書き込み権限を排除
chmod 755 /home/ubuntu
# .sshディレクトリを自分専用にする
chmod 700 /home/ubuntu/.ssh
# authorized_keysの権限を600にする
chmod 600 /home/ubuntu/.ssh/authorized_keys3. 原因を1発で特定するサーバーログの調査法
推測で権限をいじる前に、SSHサーバーが「なぜ接続を拒否したのか」のログを確認するのが解決への最短ルートです。
ログ確認コマンド
UbuntuなどのDebian系環境では、SSH認証ログは /var/log/auth.log（または systemd-journald）に記録されます。
# 直近のSSH認証ログをリアルタイム監視
sudo tail -f /var/log/auth.log | grep sshd
# Ubuntu 24.04など journald 環境の場合
sudo journalctl -u ssh -n 50 --no-pagerログから読み解く典型的なエラーメッセージ
- ホームディレクトリの権限が緩すぎる場合:
Authentication refused: bad ownership or modes for directory /home/ubuntu→ ホームディレクトリ（/home/ubuntu）に他人への書き込み権限が付いています。chmod 755 /home/ubuntu で解決します。
.ssh ディレクトリの権限が緩すぎる場合:
Authentication refused: bad ownership or modes for directory /home/ubuntu/.ssh→ chmod 700 /home/ubuntu/.ssh で解決します。
authorized_keys のファイル権限が緩すぎる場合:
Authentication refused: bad ownership or modes for file /home/ubuntu/.ssh/authorized_keys→ chmod 600 /home/ubuntu/.ssh/authorized_keys で解決します。
鍵自体の不一致や登録漏れの場合:
Connection closed by authenticating user ubuntu [preauth]- → パーミッションではなく、渡している秘密鍵と
authorized_keysに登録された公開鍵のペアが一致していません。
4. クライアント側のデバッグ（-vvv オプション）
ローカルPC（Mac/WindowsのPowerShellやWSL）から接続を試みる場合、詳細ログオプション（-v 〜 -vvv）を付けてSSHコマンドを実行すると、手元でどの鍵を試して失敗したかが丸見えになります。
ssh -vvv -i ~/.ssh/my_key.pem ubuntu@your-server-ip- ログ中に
Offering public key: ...と表示され、サーバーからServer refused our keyやNext authentication method: publickeyが返ってくる場合、サーバー側で鍵が拒否された証拠です。
まとめ
公開鍵認証の「Permission denied」トラブルに直面した際は、焦らず以下の順序でチェックしましょう。
auth.logやjournalctl -u sshでサーバー側の拒否ログを確認する- ホームディレクトリ（
755）、.ssh（700）、authorized_keys（600）の権限を正す - 所有者が
rootや別ユーザーにすり替わっていないか（chown）確認する
この防御仕様（StrictModes）はサーバーの安全を守るための必須機能です。ルールを正しく把握しておくことで、接続不能時の無駄な手戻りをゼロに抑えられます。
コメント