SSH 密钥登录排错：从 Permission denied 到一次登录成功

密钥登录失败时，先别急着换密码或反复生成新密钥。多数 Permission denied 只是某一环对不上：客户端拿错私钥、服务端没认出公钥，或文件权限被判定不安全。按客户端、服务端、权限这条线查，通常十分钟就能定位。

一、客户端：先看详细日志

用 ssh -v 连接，重点看它尝试了哪几个私钥、服务端接受哪种认证、最后在哪一步被拒绝。出现 offering public key 后被拒绝，说明私钥能读但服务端不认可；根本没有 offering，多是本地问题：路径不对、口令未解锁，或 IdentityFile 指向旧文件。先用 ls -l ~/.ssh 和 ssh-add -l 确认，再用 -i 明确指定一把钥匙复现。多钥匙混用时默认顺序一乱，服务器常先收到错误那把。

二、服务端：确认公钥真的在位

能用其他方式登录时，检查目标用户的 authorized_keys 是否完整、有无换行截断或多余空格。常见错误是把私钥贴了上去，或把一行公钥拆成两行，用 ssh-copy-id 重新分发一次最稳妥。再看 sshd 配置：PubkeyAuthentication 是否为 no，AuthorizedKeysFile 是否指向自定义路径；改完要重载 sshd。云服务器还需确认安全组放行端口、是否只允许密钥登录。

三、权限：最容易被忽视的一环

OpenSSH 对权限很严格：家目录不能被他人写入，.ssh 为 700，authorized_keys 和私钥为 600。权限一放宽，服务端可能直接忽略 authorized_keys。修复就是 chmod 700 ~/.ssh、chmod 600 ~/.ssh/authorized_keys、chmod 600 私钥文件。还要核对属主是否为当前用户，家目录是否只读。服务端日志 journalctl -u sshd 或 /var/log/auth.log 会写明是权限、密钥不匹配还是认证被禁用。

四、口令与跳板也要排除

私钥有口令要先解锁；用 ssh-agent 时确认加载的是当前这把，而非过期那把。跳板机场景把链路拆成两段分别测试，确认 ForwardAgent 是否按预期开启，比全链路猜测快得多。

五、排错清单

ssh -v 定位；确认私钥与代理状态；核对 authorized_keys 的完整性与属主；核对 sshd 配置；修正权限；看服务端日志确认原因。每改一处复测一次，不要一次改五处。结语：把“登不上去”翻译成“哪一环不信任我”，Permission denied 就成了一条可按图索骥的线索。