一次「Permission denied (publickey)」的完整排查实录


一次「Permission denied (publickey)」的完整排查实录:真正的坑在 /root 权限

记录一次真实的 SSH 公钥登录失败排查过程。
表面是 Permission denied (publickey)
实际原因却是 /root 目录权限不安全,被 OpenSSH 直接拒绝

这篇文章完整复盘我的排查路径,希望能帮你少踩一个 非常隐蔽但致命的 SSH 坑


一、问题背景

在使用 SSH key 登录服务器时,执行以下命令:

ssh -o IdentitiesOnly=yes -i ~/.ssh/key-dmit.pem root@my_server_ip

返回结果:

Permission denied (publickey).

服务器环境:

  • Debian 12
  • OpenSSH_9.x
  • root 登录
  • 已确认服务器 22 端口开放
  • 网络连通正常

二、第一步:确认网络与 SSH 服务正常

 测试 SSH 握手是否成功

ssh -vvv -i ~/.ssh/key-dmit.pem root@my_server_ip

可以看到完整的:

  • TCP 连接建立
  • SSH KEX 正常
  • Host key 校验通过

说明:

  •  不是网络问题
  •  不是端口 / 防火墙问题
  •  不是 SSH 版本不兼容

三、理解一个常被误解的提示

第一次连接服务器时,会看到:

The authenticity of host 'my_server_ip' can't be established.
Are you sure you want to continue connecting (yes/no)?

这是 SSH 的正常安全提示,不是报错。

正确操作:

yes

继续即可。


四、关键日志:-vvv 定位到服务器拒绝了 key

在 ssh -vvv 输出中,最关键的是这一段:

Offering public key: key-dmit.pem RSA SHA256:xxxx
Authentications that can continue: publickey
Permission denied (publickey).

这说明:

客户端成功提交了公钥
但服务器 明确拒绝了该 key

于是,问题一定在 服务器端


五、服务器端自检:ssh 日志是唯一真相

在服务器上执行:

journalctl -u ssh -f

然后在本地再次尝试 SSH 登录。

日志中出现了关键一行:

Authentication refused: bad ownership or modes for directory /root

 真凶出现了


六、真正的原因:/root 目录权限不安全

很多人(包括我)以为 SSH 只检查:

/root/.ssh
/root/.ssh/authorized_keys

但 OpenSSH 的安全检查是“整条路径”

/root
/root/.ssh
/root/.ssh/authorized_keys

只要其中任何一级权限不符合要求,SSH 会直接拒绝认证。

OpenSSH 对 root 的硬性要求
路径权限属主
/root700root:root
/root/.ssh700root:root
authorized_keys600root:root

哪怕:

  • /root 是 755
  • 或 group / other 有写权限

 都会直接失败,且客户端只显示 Permission denied (publickey)


七、修复方案(一次到位)

在服务器控制台 / VNC 中执行:

chown root:root /root
chmod 700 /root

mkdir -p /root/.ssh
chown root:root /root/.ssh
chmod 700 /root/.ssh

touch /root/.ssh/authorized_keys
chown root:root /root/.ssh/authorized_keys
chmod 600 /root/.ssh/authorized_keys

然后确认公钥内容正确:

ssh-keygen -y -f ~/.ssh/key-dmit.pem

将输出的一整行公钥放入:

/root/.ssh/authorized_keys

八、最终验证
ssh -i ~/.ssh/key-dmit.pem root@my_server_ip

成功登录

服务器日志显示:

Accepted publickey for root

九、顺手做的安全加固(强烈推荐)

服务器正在被全网扫描(elastic / admin / ftp 等),建议:

PasswordAuthentication no
PermitRootLogin prohibit-password

即:

  • 禁止密码登录
  • root 仅允许 key 登录

并重启 sshd:

systemctl restart sshd

十、经验总结(血的教训)
  1. Permission denied (publickey) 并不等于 key 内容错误
  2. 一定要看 服务器端 sshd 日志
  3. SSH 检查的是 整条目录权限链
  4. /root 权限问题极其隐蔽,但后果直接“死刑”
  5. journalctl -u ssh -f 是排查 SSH 的终极武器

结语

这次排查让我再次确认一件事:

不要猜 SSH,去看日志。

希望这篇记录能帮你节省至少 1 小时的无效折腾。

如果你也踩过类似的坑,欢迎交流。文章测试,说点什么呢?


发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注