应检查私钥文件（如id_rsa）权限是否为600、~/.ssh目录权限是否为700、路径中是否存在符号链接或父目录被组/其他用户写入；修复命令为chmod 600 ~/.ssh/id_rsa和chmod 700 ~/.ssh。
ssh提示“permissions are too open”时该查什么
直接报这个错，说明SSH客户端连私钥文件都不敢读——它已经放弃认证流程了。不是服务端拒绝你，是客户端自己把钥匙扔了。
核心检查点就三个：
-
~/.ssh/id_*.pub文件权限无关紧要，但私钥（如id_rsa或id_ed25519）必须是600 -
~/.ssh目录权限必须是700，不能是755或更宽松 - 私钥路径里不能有符号链接，且所有父目录都不能被组/其他用户写入（比如
/home/user是775就会触发拒绝）
执行 ls -l ~/.ssh/id_* 和 ls -ld ~/.ssh 看一眼，基本就能定位。修复命令就是：chmod 600 ~/.ssh/id_ed25519 和 chmod 700 ~/.ssh。
服务端报“Permission denied (publickey)”但客户端没报权限错
这时候问题大概率不在私钥本身，而是服务端加载公钥失败。常见原因不是配置没开，而是路径上某一级权限太松。
OpenSSH 在 StrictModes yes（默认开启）下会逐级校验整个路径链：从 / → /home/user → /home/user/.ssh → /home/user/.ssh/authorized_keys。只要其中任意一级对 group 或 other 开了写权限（比如 /home/user 是 775），sshd 就会静默跳过 authorized_keys，不报错也不提示，只返回 Permission denied (publickey)。
快速验证命令：ls -ld /home/your_username ~/.ssh ~/.ssh/authorized_keys。重点关注第一列输出里的 w 是否出现在 group 或 other 位（如 drwxrwxr-x 中第二个 w 就违规）。
修复方式：
- 重设主目录权限：
chmod 755 /home/your_username - 确认属主：
chown your_username:your_username /home/your_username - 再跑一遍：
chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys
ssh -v 日志里出现 “Server accepts key” 却仍登录失败
这说明服务端找到了你的公钥，也发出了挑战，但客户端没能正确响应——十有八九是私钥加载失败或签名出错。
除了权限问题，还要注意：
- 私钥是否带口令？如果带了但没输入，或者 GUI 工具（如 VSCode Remote-SSH、Xshell）没在连接设置里勾选“使用密钥口令”，就会卡在这一步
- 私钥格式是否兼容？OpenSSH 8.8+ 默认生成的
id_ed25519是新格式（OPENSSH PRIVATE KEY），老版本客户端可能不认；若需兼容，生成时加-m PEM参数 - 客户端是否用了错误的私钥？比如本地有多个密钥，但没用
-i指定，SSH 就按默认顺序尝试，可能先试了权限错误的那个，然后跳过正确的
验证方法：ssh -i ~/.ssh/id_ed25519 -v user@host 显式指定，并观察日志中 Offering public key 后是否跟了 Server accepts key，再看有没有 Authentication succeeded。
authorized_keys 文件内容看似正常却无效
服务端不会告诉你哪一行公钥坏了，只会整行跳过。最常踩的坑是手动编辑引入了不可见字符。
典型失效场景：
- Windows 编辑器保存的
authorized_keys带 BOM 或 CRLF 换行符 - 复制公钥时多选了一个空格、换行或制表符，导致整行格式错乱
- 公钥被截断（比如只复制了前半段 SHA256 值）
- 文件编码不是 UTF-8，或混入了中文注释（虽然允许注释，但某些旧版 sshd 对非 ASCII 字符敏感）
安全做法永远是用 ssh-copy-id 部署：ssh-copy-id -i ~/.ssh/id_ed25519.pub user@host。如果必须手动操作，就用 cat ~/.ssh/id_ed25519.pub | ssh user@host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"，避免本地编辑器污染。
真正麻烦的从来不是“哪里错了”，而是“哪里看起来没错”。权限检查链条长、静默失败多、日志提示模糊——这些设计本意是安全，结果成了排查黑洞。每次改完权限，别忘了 sudo systemctl restart sshd（部分系统需重启生效），也别跳过 ssh -v 那几行 debug 输出，它们才是唯一说实话的地方。
