SSH 报 UNPROTECTED PRIVATE KEY FILE / Permissions ... are too open（私钥权限过宽）

你会遇到什么

用 ssh -i 私钥 登录时报整屏 WARNING: UNPROTECTED PRIVATE KEY FILE!，Permissions 0644 for '/path/id_rsa' are too open，最后 Permission denied (publickey)。密钥文件本身没问题，你也没改过任何东西——只是文件权限太宽被 OpenSSH 拒了。

常见于从压缩包/网盘拷来的密钥、Windows 工具生成的密钥（0644）、或 WSL 挂载 Windows 盘的密钥（chmod 看着生效实际无效）。

本文路径：快速修复（30 秒一段命令）→ 一步步排查（可跳读）→ 原理与变体（症状/原因/证据）。赶时间直接跳到「快速修复」。

为什么会这样

OpenSSH 客户端加载私钥时强制要求：私钥不能被其他用户/组读取（必须是 600/700 级别）。一旦 group/other 有读权限（644/640/664 等），直接忽略该密钥并拒绝用其认证——这是防私钥泄露的安全设计，不是故障。

• 注意该检查在认证阶段才触发（需先建立 TCP 连接），所以连不上服务器时看不到这个警告。
• WSL 里挂载 /mnt/c 的密钥：drvfs 文件系统不支持 chmod，chmod 600 看着生效实际无效——必须把密钥复制进 WSL 再改，或用 icacls 在 Windows 侧修。

实测环境：WSL Ubuntu，OpenSSH 10.2p1，本机临时 sshd（127.0.0.1:2222），2026-08-29。

OpenSSH 客户端在认证阶段强制校验私钥文件权限：group/other 有读权限（644/640/664 等）就静默忽略该密钥（Load key ... bad permissions），这是防私钥泄露的安全设计，不是故障——私钥就是密码，任何人都能读的密码等于没有密码。检查发生在认证阶段（建立 TCP 连接后），所以连不上服务器时看不到警告。

WSL 挂载盘（/mnt/c）的 drvfs 不支持 chmod：chmod 600 表面成功实际无效（文件仍按挂载默认权限暴露）。

确定性推论：Load key ... bad permissions = 权限不对，chmod 600 ~/.ssh/id_xxx 即修（目录也建议 700）；WSL 里密钥放 ~/.ssh/（WSL 文件系统）而不是 /mnt/c；ssh -v 看详细加载过程定位「忽略」原因；判断路径：警告出现在认证阶段 = 权限问题，不是网络/服务器问题。

一步步来

1. 确认是权限问题 — 必做

ls -l ~/.ssh/id_ed25519

权限是 -rw-r--r--（644）或 -rw-r-----（640）→ 就是这个问题（实测：644 和 640 都触发警告，exit 255）。

2. 改私钥权限 — 必做

chmod 600 ~/.ssh/id_ed25519

公钥 644 无妨；~/.ssh 目录本身别 777（chmod 700 ~/.ssh）。

3. Windows 工具/WSL 挂载盘的密钥 — 必做

• WSL 访问 /mnt/c 上的密钥：先 cp 到 WSL 内（如 ~/.ssh/）再 chmod 600；
• Windows 原生 OpenSSH：icacls "私钥路径" /inheritance:r /grant:r "%USERNAME%:R"；
• 工具生成的临时密钥（az bastion ssh 等 /tmp 密钥）：先 chmod 600 再用。

4. 批量修复注意 — 必做

chmod 600 ~/.ssh/* 会误伤公钥（公钥 600 也行，只是没必要）；精确一点只改无 .pub 的文件。

怎么确认修好了

ssh -i ~/.ssh/id_ed25519 user@host

不再出现 UNPROTECTED PRIVATE KEY FILE 警告、能免密登录即成功。实测：私钥 600 → 登录成功（exit 0）；644/640 → 警告 + Permission denied（exit 255）；改回 600 → 恢复成功。

其它环境的表现

症状

用 ssh -i 私钥 登录时整屏警告：

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/path/id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/path/id_rsa": bad permissions
root@host: Permission denied (publickey,keyboard-interactive).

特征：密钥文件本身没问题，是文件权限被 ssh 拒绝（组/其他人可读就报）； 常见于从压缩包/网盘拷来的密钥、Windows 工具生成的密钥（azure-cli-extensions#6408 就是工具生成 0644 密钥）、 或 WSL 里挂载 Windows 盘的密钥（chmod 无效）。

原因

OpenSSH 客户端加载私钥时强制要求：私钥不能被其他用户/组读取（必须是 600/700 级别）。 一旦 group/other 有读权限（644/640/664 等），直接忽略该密钥并拒绝用其认证——这是防私钥泄露的安全设计，不是故障。 注意：该检查在认证阶段才触发（需要先建立 TCP 连接），所以连不上服务器时看不到这个警告。

解法

1. 改权限（Linux/macOS/WSL）：chmod 600 ~/.ssh/id_ed25519（私钥），chmod 644 公钥、chmod 700 ~/.ssh；
2. Windows 原生 OpenSSH：chmod 不适用，用 icacls "私钥路径" /inheritance:r /grant:r "%USERNAME%:R"；
3. WSL 访问 /mnt/c 上的密钥：drvfs 不支持 chmod（chmod 看着生效实际无效），

正确做法把密钥复制到 WSL 内（cp + chmod 600）或用 icacls 在 Windows 侧修；

1. 工具生成的临时密钥（az bastion ssh / 各类 CLI 的 /tmp 密钥）：先 chmod 600 再用，或反馈工具修复（#6408 场景）；
2. 检查父目录：~/.ssh 目录本身别 777（chmod 700 ~/.ssh）；
3. 批量修复：chmod 600 ~/.ssh/* 会误伤公钥（公钥 644 无妨，600 也行），精确一点只改无 .pub 的文件。