authorized_keysの権限とchmod｜.sshの所有者・設定確認
authorized_keysの権限を調べると「chmod 600」「.sshは700」という例をよく見ます。ただし、SSH公開鍵認証では数値だけでなく、所有者・親ディレクトリ・実際に参照されるAuthorizedKeysFileまで確認することが重要です。このページでは、変更前の確認コマンドから安全な修正例まで順に整理します。
このページで分かること
- 秘密鍵・
.ssh・authorized_keysの役割の違い chmod 700 ~/.ssh・chmod 600 ~/.ssh/authorized_keysの意味stat・nameiで所有者や親ディレクトリまで確認する方法sshd -Tで実際の公開鍵ファイル設定を確認する方法- 設定値が正しいのに認証できない場合の次の確認先
先に結論
一般的には、クライアントの~/.sshは700、秘密鍵は600程度に制限し、サーバー側の~/.sshとauthorized_keysも対象ユーザーが所有し、他ユーザーから不用意に書き換えられない状態にします。数値だけでなく所有者・親ディレクトリ・実効設定まで確認するのがポイントです。
authorized_keys permissions：まず確認する値
よく使われる安全側の例は、サーバー側の ~/.ssh が 700、authorized_keys が 600 です。ただし「600なら必ず通る」という意味ではなく、所有者・親ディレクトリ・sshdの実効設定も合わせて確認します。
| 確認対象 | 一般的な例 | 最初の確認 |
|---|---|---|
サーバー側 ~/.ssh | 700 | stat -c "%A %a %U:%G %n" ~/.ssh |
サーバー側 authorized_keys | 600 | stat -c "%A %a %U:%G %n" ~/.ssh/authorized_keys |
| ホームから鍵ファイルまで | 所有者・書込権限を確認 | namei -l ~/.ssh/authorized_keys |
| sshdの実効設定 | 環境依存 | sshd -T で AuthorizedKeysFile / StrictModes を確認 |
stat -c '%A %a %U:%G %n' ~/.ssh ~/.ssh/authorized_keys namei -l ~/.ssh/authorized_keys sudo sshd -T | grep -E '^(authorizedkeysfile|pubkeyauthentication|strictmodes) '
Permission denied (publickey) が出ている場合：権限だけを直す前に、Permission denied (publickey) の切り分け手順で、接続ユーザーと実際に使われる鍵から確認してください。権限表記を確認する
700や600が誰にどの権限を与えるか、Linux権限計算ツールで確認できます。
秘密鍵・公開鍵・authorized_keysの役割を分ける
SSH公開鍵認証では、クライアント側とサーバー側で置くものが違います。権限問題を確認するときは、まず「どのファイルを見ているのか」を分けます。
| 場所 | 対象 | 役割 |
|---|---|---|
| クライアント | ~/.ssh/id_ed25519 など | 秘密鍵。本人だけが扱えるよう厳しく保護する |
| クライアント | ~/.ssh/id_ed25519.pub など | 公開鍵。接続先へ登録するための情報 |
| サーバー | ~/.ssh/authorized_keys | そのユーザーへのログインに許可する公開鍵の一覧 |
authorized_keysへ貼り付けるものではありません。authorized_keysへ登録するのは公開鍵です。.sshとauthorized_keysでよく使われる権限の目安
次は一般的によく使われる設定例です。OpenSSHは特に、認証に使うファイルが他ユーザーから書き換え可能な状態を警戒します。
| 対象 | よく使われる例 | 確認したいこと |
|---|---|---|
~/.ssh | 700 | 所有者だけが一覧・作成・移動できる |
| 秘密鍵 | 600 | 所有者だけが読み書きできる |
authorized_keys | 600 | 他ユーザーから書き換えられない |
公開鍵 *.pub | 644 など | 秘密情報ではないが、不必要な書込権限は付けない |
chmodするより、現在のモードと所有者を記録してから変更すると切り戻しや原因特定がしやすくなります。700・600は一般的な安全側の設定例です。重要なのは、認証に使うファイルやディレクトリが意図しないユーザーから書き換え可能になっていないことと、所有者が想定どおりであることです。OpenSSHのStrictModesはログイン前にユーザーのファイルやホームディレクトリのモード・所有者を確認します。
所有者と親ディレクトリも確認する
サーバー側では、接続対象ユーザーのホームディレクトリから.ssh、authorized_keysまでを確認します。authorized_keysだけが正しくても、所有者が別ユーザーだったり、上位ディレクトリが不用意に書き換え可能だったりすると公開鍵認証で問題になることがあります。
namei -lは、/home → appuser → .ssh → authorized_keysの各段階を一度に見られるため、「ファイルは600なのに認証できない」というときの確認に向いています。
修正が必要な場合は、対象と現在値を確認してから必要な場所だけ変更します。運用ルールや共有グループ、ACLを使っている環境では既存要件を優先してください。
StrictModesが有効な場合、ログインを受け付ける前にユーザーのファイルやホームディレクトリの所有者・モードが適切か確認されます。実効値はsshd -Tで確認できます。statで数値モードと所有者 → namei -lで親ディレクトリ → sshd -Tで実際の参照先、の順に見ると「600なのに接続できない」を切り分けやすくなります。AuthorizedKeysFileとStrictModesの実効設定を確認する
authorized_keysを正しい場所へ置いたつもりでも、サーバー側設定で別のパスを参照している可能性があります。設定ファイルを目視するだけでなく、可能ならsshd -Tで実効値を確認します。
AuthorizedKeysFileにはユーザーのホームディレクトリからの相対パスなどを指定できます。環境独自のsshd_config.d設定がある場合、想定していた~/.ssh/authorized_keys以外を参照していることもあります。
sshd -Tだけでは接続条件ごとのMatch設定を反映できない場合があります。対象ユーザーや接続元アドレスに応じた実効値を確認する場合は、環境に合わせて-Cで接続条件を指定します。sshd_configを修正する場合は、現在のSSHセッションを残したままsudo sshd -tで構文確認し、別セッションから新規接続できることを確認してから既存接続を閉じます。秘密鍵の「bad permissions」はクライアント側を確認する
WARNING: UNPROTECTED PRIVATE KEY FILE!やLoad key ...: bad permissionsのような表示は、接続先のauthorized_keysではなく、まずクライアント側の秘密鍵ファイルの権限を確認します。
一方、Permission denied (publickey)は「秘密鍵の権限」だけが原因とは限りません。ユーザー名、実際に使用した鍵、公開鍵の登録、サーバー側設定など複数の確認が必要です。
公開鍵を登録するときの安全な確認手順
- 接続対象ユーザーとホームディレクトリを確認する
- 公開鍵を対象ユーザーの許可ファイルへ登録する
.ssh・authorized_keysの所有者とモードを確認するsshd -TでAuthorizedKeysFile・PubkeyAuthentication・StrictModesを確認する- クライアント側で使用する秘密鍵を明示し、別セッションから接続テストする
- 失敗した場合は
ssh -vvvとサーバー側ログで認証段階を確認する