SSH で「UNPROTECTED PRIVATE KEY FILE」が出て鍵が使えない

秘密鍵ファイルが本人以外から読める権限になっていると、OpenSSH はその鍵を無視して接続を拒否する。chmod 600 で本人だけが読み書きできる状態にすれば解消する。~/.ssh 自体の権限も同時に見直す。

#ssh #permission #chmod #private-key #openssh

公開: 2026-08-10更新: 2026-09-12

実行例あり（2026-09-12 に実環境で検証）

要約

OpenSSH は、秘密鍵が本人以外から読める状態なら鍵ごと無視する。
鍵の内容やサーバー側の設定は関係なく、ローカルのファイル権限だけが原因である。

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/user/.ssh/id_ed25519' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.

最後の 1 行が本質で、鍵が使われないまま認証に進むため、続けて Permission denied (publickey) になることが多い。ssh(1) は秘密鍵について「本人が読めるだけで、他者からはアクセスできない状態であるべき」と定めている。

実行例

0644 のままの秘密鍵を指定して接続すると、OpenSSH は UNPROTECTED PRIVATE KEY FILE! を表示して鍵を読み込まず、認証は Permission denied（publickey）で終了コード 255 になった。chmod 600 で 0600 に絞ったあと、同じコマンドがそのまま認証を通り、リモートの uname -sr の出力が返っている。

セットアップ: 127.0.0.1:2222 に sshd を起動した

$ ls -l /root/.ssh/id_ed25519
-rw-r--r--    1 root     root           411 Sep 12 02:48 /root/.ssh/id_ed25519

$ ssh -o StrictHostKeyChecking=no -o BatchMode=yes -p 2222 -i /root/.ssh/id_ed25519 root@127.0.0.1 uname -sr
Warning: Permanently added '[127.0.0.1]:2222' (ED25519) to the list of known hosts.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/root/.ssh/id_ed25519' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/root/.ssh/id_ed25519": bad permissions
root@127.0.0.1: Permission denied (publickey,password,keyboard-interactive).
$ echo $?
255

$ chmod 600 /root/.ssh/id_ed25519

$ ls -l /root/.ssh/id_ed25519
-rw-------    1 root     root           411 Sep 12 02:48 /root/.ssh/id_ed25519

$ ssh -o StrictHostKeyChecking=no -o BatchMode=yes -p 2222 -i /root/.ssh/id_ed25519 root@127.0.0.1 uname -sr
Linux 6.6.87.2-microsoft-standard-WSL2
$ echo $?
0

— 2026-09-12 時点の出力

検証環境

検証日: 2026-09-12
実行環境: alpine:3Alpine Linux v3.24

この記事の「実行例」は、上記の環境で実際にコマンドを実行して得られた出力をそのまま掲載しています。再現手順はリポジトリの検証スクリプトとして管理し、定期的に再実行して出力を更新しています。

よくある原因

権限が緩い: 0644 や 0664 が典型。git clone した設定リポジトリから鍵を展開した、cp でコピーしたといった場面で起きる。
~/.ssh 自体が緩い: 鍵の権限が正しくても、ディレクトリが他人から書き込める状態だと拒否されることがある。
WSL から Windows 側の鍵を使っている: /mnt/c 配下は既定で 0777 相当に見えるため、chmod しても保持されない場合がある。
所有者が違う: sudo を付けて操作した結果、root 所有のまま残っている。

解決策

1. 権限を絞る

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
ls -l ~/.ssh

秘密鍵は 600（-rw-------）、ディレクトリは 700（drwx------）が基準である。
公開鍵と known_hosts は他者から読めても問題ない。

2. 所有者を直す

chown "$USER:$USER" ~/.ssh ~/.ssh/id_ed25519

ls -l の所有者が自分でなければ、権限を変える前にこれを行う。

3. WSL では Linux 側に鍵を置く

cp /mnt/c/Users/you/.ssh/id_ed25519 ~/.ssh/
chmod 600 ~/.ssh/id_ed25519

/mnt/c 配下のまま使うと、chmod しても再マウントで権限が戻り、同じエラーを繰り返す。
Linux 側のホームへコピーしてから権限を設定するのが確実である。
コピー元の鍵が不要になったら消しておく。

4. 直ったかを確認する

ssh -T git@github.com

警告が出なくなり、鍵が読み込まれていれば次の段階（認証の成否）へ進む。ssh -v を付けると、どの鍵ファイルを試したかが行単位で出るので切り分けに使える。

要約

実行例