Windows SSH 报 Bad permissions：原来私钥文件的 ACL 也会被检查

第一次遇到 Windows SSH 客户端提示私钥的 Bad permissions，直觉容易放在远端服务器：是不是 SSH 端口、用户名或密钥本身出了问题？

这类报错实际值得先检查本机的私钥文件访问控制列表（ACL）。SSH 不希望保存登录凭据的文件对过多用户或群组开放，因此会拒绝加载权限不合要求的私钥。

Windows 不是简单的 chmod 600

在 Linux 里，很多教程会让人执行 chmod 600 key.pem。但 NTFS 文件通常采用 ACL 和继承机制。复制文件、从压缩包解压或移动到共享目录后，可能出现额外的用户/组读取权限。

原 Note 研究过通过 Windows 的 icacls 检查和修正私钥权限，并特别标记了一个容易踩的细节：CMD 和 PowerShell 在变量展开、引号与命令语法上并不完全相同。直接把某篇教程里的命令从一个 Shell 粘到另一个 Shell，可能连 ACL 都没有按预期设置。

应该先验证什么

• 当前 SSH 客户端实际读取的是哪一份密钥文件；
• 文件所在目录和文件本身有哪些允许读取的主体；
• 权限来自继承，还是显式授权；
• 修正后权限清单是否符合只让预期账户读取的原则；
• 如果 SSH 仍然失败，是否已经转成远端 authorized_keys、账户或网络问题。

这次排障让我意识到，认证失败不一定要先从服务器端查起。遇到 Bad permissions，先核对本机文件 ACL，再检查远端密钥授权，更容易缩小范围。