インフラ作業支援ラボInfra Support Lab← ガイド一覧← 戻る
トップ > ガイド > authorized_keysと.sshの権限｜SSH公開鍵認証の安全な設定と確認方法
SSH個別テーマガイド｜更新日：2026年8月8日

authorized_keysと.sshの権限｜SSH公開鍵認証の安全な設定と確認方法

authorized_keysや.sshの権限は、SSH公開鍵認証が成立するための重要な確認項目です。単にchmod 600にすればよいのではなく、クライアント側の秘密鍵とサーバー側の所有者・ディレクトリ権限を分けて確認します。

このページで分かること

  • 秘密鍵・.ssh・authorized_keysの役割の違い
  • よく使われる700・600の意味
  • 所有者や親ディレクトリまで確認する理由
  • sshd -Tで実際の公開鍵ファイル設定を確認する方法
  • 設定値が正しいのに認証できない場合の次の確認先

先に結論

このページの役割： SSH全体の設定方法ではなく、公開鍵認証で迷いやすい「鍵ファイル・ディレクトリの権限と所有者」に特化します。SSH接続全体の準備はSSH作業ガイド、すでに接続できない場合はSSH接続トラブルガイドを参照してください。

一般的には、クライアントの~/.sshは700、秘密鍵は600程度に制限し、サーバー側の~/.sshとauthorized_keysも対象ユーザーが所有し、他ユーザーから不用意に書き換えられない状態にします。数値だけでなく所有者・親ディレクトリ・実効設定まで確認するのがポイントです。

権限表記を確認する

700や600が誰にどの権限を与えるか、Linux権限計算ツールで確認できます。

Linux権限計算を使う

秘密鍵・公開鍵・authorized_keysの役割を分ける

SSH公開鍵認証では、クライアント側とサーバー側で置くものが違います。権限問題を確認するときは、まず「どのファイルを見ているのか」を分けます。

場所対象役割
クライアント~/.ssh/id_ed25519 など秘密鍵。本人だけが扱えるよう厳しく保護する
クライアント~/.ssh/id_ed25519.pub など公開鍵。接続先へ登録するための情報
サーバー~/.ssh/authorized_keysそのユーザーへのログインに許可する公開鍵の一覧
注意：秘密鍵をサーバーのauthorized_keysへ貼り付けるものではありません。authorized_keysへ登録するのは公開鍵です。

.sshとauthorized_keysでよく使われる権限の目安

次は一般的によく使われる設定例です。OpenSSHは特に、認証に使うファイルが他ユーザーから書き換え可能な状態を警戒します。

対象よく使われる例確認したいこと
~/.ssh700所有者だけが一覧・作成・移動できる
秘密鍵600所有者だけが読み書きできる
authorized_keys600他ユーザーから書き換えられない
公開鍵 *.pub644 など秘密情報ではないが、不必要な書込権限は付けない
chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys chmod 600 ~/.ssh/id_ed25519

ただし、数字だけを合わせれば必ず認証できるわけではありません。所有者、ホームディレクトリ、ACL、SELinux、sshdの実効設定も認証可否に影響します。

所有者と親ディレクトリも確認する

サーバー側では、接続対象ユーザーのホームディレクトリから.ssh、authorized_keysまでを確認します。authorized_keysだけが正しくても、所有者が別ユーザーだったり、上位ディレクトリが不用意に書き換え可能だったりすると公開鍵認証で問題になることがあります。

# 対象ユーザーとホームディレクトリを確認 getent passwd appuser # パスを途中のディレクトリごとに確認 namei -l /home/appuser/.ssh/authorized_keys # 所有者・モードを確認 ls -ld /home/appuser /home/appuser/.ssh ls -l /home/appuser/.ssh/authorized_keys

必要に応じて、対象ユーザーが所有するように修正します。運用ルールがある環境では、既存要件を確認してから変更してください。

sudo chown -R appuser:appuser /home/appuser/.ssh sudo chmod 700 /home/appuser/.ssh sudo chmod 600 /home/appuser/.ssh/authorized_keys
StrictModes：OpenSSHのStrictModesが有効な場合、ログインを受け付ける前にユーザーのファイルやホームディレクトリの所有者・モードが適切か確認されます。実効値はsshd -Tで確認できます。

AuthorizedKeysFileとStrictModesの実効設定を確認する

authorized_keysを正しい場所へ置いたつもりでも、サーバー側設定で別のパスを参照している可能性があります。設定ファイルを目視するだけでなく、可能ならsshd -Tで実効値を確認します。

sudo sshd -T | grep -E '^(authorizedkeysfile|pubkeyauthentication|strictmodes) '

AuthorizedKeysFileにはユーザーのホームディレクトリからの相対パスなどを指定できます。環境独自のsshd_config.d設定がある場合、想定していた~/.ssh/authorized_keys以外を参照していることもあります。

設定変更前：sshd_configを修正する場合は、現在のSSHセッションを残したままsudo sshd -tで構文確認し、別セッションから新規接続できることを確認してから既存接続を閉じます。

秘密鍵の「bad permissions」はクライアント側を確認する

WARNING: UNPROTECTED PRIVATE KEY FILE!やLoad key ...: bad permissionsのような表示は、接続先のauthorized_keysではなく、まずクライアント側の秘密鍵ファイルの権限を確認します。

ls -l ~/.ssh/id_ed25519 chmod 600 ~/.ssh/id_ed25519 ssh -i ~/.ssh/id_ed25519 user@example-server

一方、Permission denied (publickey)は「秘密鍵の権限」だけが原因とは限りません。ユーザー名、実際に使用した鍵、公開鍵の登録、サーバー側設定など複数の確認が必要です。

すでに認証エラーが出ている場合： SSH接続トラブルガイドの公開鍵認証チェックへ →

公開鍵を登録するときの安全な確認手順

  1. 接続対象ユーザーとホームディレクトリを確認する
  2. 公開鍵を対象ユーザーの許可ファイルへ登録する
  3. .ssh・authorized_keysの所有者とモードを確認する
  4. sshd -TでAuthorizedKeysFile・PubkeyAuthentication・StrictModesを確認する
  5. クライアント側で使用する秘密鍵を明示し、別セッションから接続テストする
  6. 失敗した場合はssh -vvvとサーバー側ログで認証段階を確認する
# クライアント側：使用するユーザー・鍵を明示して確認 ssh -vvv -i ~/.ssh/id_ed25519 appuser@example-server
確認ポイント：「600にしたからOK」ではなく、どのユーザーへ、どの公開鍵を、どのファイルへ登録し、実際にどの秘密鍵で接続したかを対応付けて確認すると、設定ミスを減らせます。

700・600の権限を確認する

Linux権限計算ツールで、所有者・グループ・その他に付く権限を確認できます。

Linux権限計算を使う