SSH密钥登录偶发Permission denied (publickey)问题排查求助

数据老陈

2026-5-19

偶发「Permission denied (publickey)」问题的排查思路

嘿，我之前维护过配置类似的服务器，也碰到过这种偶发的SSH密钥认证失败情况，结合你给出的环境（完全更新的Ubuntu 16.04 LTS、禁用密码/root登录，多客户端都出现问题），给你整理几个实用的排查方向：

优先查服务器端的认证日志
这比客户端的ssh -vvv输出靠谱多了——毕竟你说失败和成功的客户端日志差异极小，服务器端的/var/log/auth.log会直白告诉你拒绝的原因。建议在某次失败后立刻登录服务器（比如用物理控制台或者其他备用方式），执行：
```
tail -n 20 /var/log/auth.log
```
重点关注包含sshd和publickey的条目，比如有没有error: key_read: uudecode error（密钥解码错误）、error: authorized_keys:X: invalid key（authorized_keys格式异常）这类提示，说不定能直接揪出偶发问题的根源。
排查客户端的ssh-agent缓存问题
不管是OSX还是Ubuntu客户端，如果你依赖ssh-agent缓存密钥，偶发的代理失效可能导致认证失败——比如OSX的ssh-agent在系统休眠后偶尔会抽风，Ubuntu的代理也可能因为内存回收等原因出现异常。
你可以在失败时试试重新添加密钥到代理：
```
# OSX系统
ssh-add -K ~/.ssh/你的私钥文件名
# Ubuntu系统
ssh-add ~/.ssh/你的私钥文件名
```
再尝试连接；也可以直接绕开代理，指定密钥文件连接测试：
```
ssh -i ~/.ssh/你的私钥文件名 用户名@服务器地址
```
如果这样就不再失败，那大概率是ssh-agent的偶发问题。
检查sshd服务的配置参数
虽然你说系统已经完全更新，但有些默认配置可能触发偶发限制：
- MaxStartups：这个参数控制同时允许的未认证连接数，默认是10:30:100，如果客户端频繁重试或者有其他并发连接，可能触发这个限制导致偶发拒绝。可以修改/etc/ssh/sshd_config，把它改成MaxStartups 100:30:200或者更高，然后重启sshd：sudo systemctl restart sshd
- 顺带确认PubkeyAuthentication yes和AuthorizedKeysFile ~/.ssh/authorized_keys这两个配置是否正确，虽然你大部分时候能成功，但偶尔的配置重载异常也可能出问题。
排查网络层面的偶发丢包
有时候看起来是认证问题，实则是网络丢包导致密钥交换的数据包丢失，进而触发认证失败。你可以在客户端用mtr 服务器地址测试一段时间，看看有没有丢包情况；或者用ping -c 100 服务器地址持续测试，观察是否有丢包。如果存在偶发丢包，那可能需要排查网络链路的问题。
验证密钥文件的完整性
概率较低，但偶发的磁盘IO异常可能导致客户端私钥或服务器端authorized_keys文件损坏。你可以在客户端执行ssh-keygen -y -f ~/.ssh/你的私钥文件名验证私钥是否正常，服务器端执行ssh-keygen -lf ~/.ssh/authorized_keys检查公钥格式是否正确。

内容的提问来源于stack exchange，提问作者flindeberg