linux Troubleshooting
SSH Permission denied (publickey) 排查流程
ssh 或 git 拉代码报 Permission denied (publickey) 时，先用 ssh -vvv 看客户端提交了哪把 key 和服务端 Authentications that can continue，再核对 authorized_keys 内容、~/.ssh 目录 700 与 authorized_keys 600 权限，云服务器还要检查 sshd_config 和安全组。
先用 ssh -vvv 看客户端到底提交了哪把 key，再检查服务端用户、authorized_keys 内容和目录权限。不要只盯着密钥文件是否存在。
Scenario
这篇文章解决什么问题
适用于 ssh 或 git clone 报 Permission denied (publickey) 的场景。排查核心是用 ssh -vvv 看客户端到底提交了哪把 key、服务端为什么拒绝，而不是反复生成新 key。
Symptoms
典型现象
- ssh 或 git clone 报 Permission denied (publickey)。
- ssh -vvv 输出中 Offering public key 后接 Server refused our key。
- 明明 id_rsa 存在但 ssh 没有提交这把 key（被 ssh config 或 IdentitiesOnly 影响）。
- 同一把 key 在一台机器能用，在另一台机器不能用。
Before Debugging
排查前先确认
- 先确定故障资源：CPU、内存、磁盘、网络、权限、文件句柄还是 systemd 生命周期。
- 区分当前状态和故障发生时状态，事故恢复后 free/top 可能已经看不出根因。
- 任何清理或 kill 操作前先记录 PID、命令行、日志和影响范围。
Root Causes
常见根因分层
资源耗尽或限制过低
磁盘、内存、CPU、load、文件句柄和进程数限制都会让服务表现为启动失败、连接失败或随机超时。
- 先看系统级指标，再看进程级指标
- 确认 systemd/cgroup 限制
- 保留 dmesg/journalctl 历史证据
运行环境和交互 shell 不一致
systemd 服务没有你的 shell 环境变量、工作目录和 PATH；手动能跑不代表服务单元能跑。
- ExecStart 使用绝对路径
- 设置 WorkingDirectory 和 EnvironmentFile
- 修改 unit 后 daemon-reload
文件、权限和句柄生命周期异常
权限不对、文件已删除但仍被进程持有、日志无限增长、fd 泄漏都会造成表象复杂的问题。
- 用 lsof +L1 查 deleted 文件
- 检查目录权限和属主
- 看 /proc/<pid>/limits
Diagnosis Path
分步诊断流程
1. 固定现场，避免追着变化状态跑
先记录故障时间、影响入口、完整错误和最近一次变更。SSH Permission denied (publickey) 排查流程 这类问题经常在重启、重试或缓存刷新后短暂消失，没有现场信息会很难复盘。
- 截图或保存完整错误文本
- 记录请求域名/IP/端口/namespace/服务名
- 标出最近发布、配置、证书、镜像或依赖变更
ssh -vvv user@host
ssh -i ~/.ssh/id_ed25519 user@host2. 在故障发生的同一位置复现
很多误判来自测试位置不同：本机通不代表服务器通，容器内通不代表宿主机通，集群外通也不代表 Pod 内通。复现命令要尽量贴近真实流量路径。
- 从报错服务所在机器执行测试
- 必要时加 Host、SNI、namespace 或代理参数
- 把成功路径和失败路径的输出并排比较
ssh -i ~/.ssh/id_ed25519 user@host
ls -ld ~/.ssh && ls -l ~/.ssh/authorized_keys
sudo tail -n 100 /var/log/auth.log3. 读取服务端证据，而不是只看客户端提示
客户端报错通常是结果摘要。真正能区分根因的是服务端日志、内核日志、事件、进程状态或数据库状态。
- 确认用户名和目标主机正确，尤其是 Git 仓库地址中的用户固定为 git。
- 用 -vvv 查看 Offering public key 和 Authentications that can continue。
- 确认公钥内容已完整写入服务端对应用户的 authorized_keys。
ls -ld ~/.ssh && ls -l ~/.ssh/authorized_keys
sudo tail -n 100 /var/log/auth.log
ssh -T git@github.com4. 做最小修复并立即回归验证
每次只改一个变量，修复后用同一条复现命令回测，并观察日志是否停止增长。这样可以避免多个临时改动互相掩盖。
- 确认公钥内容已完整写入服务端对应用户的 authorized_keys。
- 修复 ~/.ssh 目录 700、authorized_keys 600、用户家目录不可被其他用户写。
- 如果是云服务器，检查安全组、sshd_config 和是否禁用了对应认证方式。
sudo tail -n 100 /var/log/auth.log
ssh -T git@github.comCommands
排查命令与使用意图
命令 1
用于确认 Git/SSH 的最终配置和认证链路。注意输出中可能包含仓库地址、用户名或代理信息，分享前应脱敏。
ssh -vvv user@host命令 2
用于确认 Git/SSH 的最终配置和认证链路。注意输出中可能包含仓库地址、用户名或代理信息，分享前应脱敏。
ssh -i ~/.ssh/id_ed25519 user@host命令 3
用于确认 Git/SSH 的最终配置和认证链路。注意输出中可能包含仓库地址、用户名或代理信息，分享前应脱敏。
ls -ld ~/.ssh && ls -l ~/.ssh/authorized_keys命令 4
用于读取日志或配置文件内容。重点看时间戳附近的 ERROR、FATAL、refused、timeout 等关键词。
sudo tail -n 100 /var/log/auth.log命令 5
用于确认 Git/SSH 的最终配置和认证链路。注意输出中可能包含仓库地址、用户名或代理信息，分享前应脱敏。
ssh -T git@github.comRisk Notes
容易踩坑的地方
- ~/.ssh 目录权限必须 700，authorized_keys 必须 600，家目录不能被其他用户写——权限不对是 SSH 拒绝的最常见原因。
- SELinux 也会导致 authorized_keys 读取失败，restorecon -R ~/.ssh 可以修复。
- ssh-agent 转发可能导致提交了错误的 key，用 ssh -i 显式指定 key 更可靠。
Verification
修复后怎么确认
- 原始故障现象已经消失，且使用同一入口重新测试 SSH Permission denied (publickey) 能稳定成功。
- 服务端日志不再出现同类错误，监控中的错误率、重启次数、连接数或延迟回到正常区间。
- 如果做过临时绕过，已经记录恢复计划，例如还原宽松策略、补监控、补限制或提交正式配置。
Prevention
后续预防
- 统一用 ed25519 key（更短更安全），把 ssh config 写好 Host 别名和 IdentityFile。
- 新服务器初始化时用 ssh-copy-id 自动处理权限和 authorized_keys 内容。
- Git 仓库地址中用户名固定为 git（如 git@github.com），不要用个人用户名。
常见问题
为什么指定 -i 仍然不用这把 key？
可能被 ssh config、IdentitiesOnly、Host 匹配顺序或代理转发影响。用 ssh -G host 查看最终配置。
Windows 上 Git SSH 失败怎么办？
先确认 Git 使用的是哪套 ssh.exe，再用 GIT_SSH_COMMAND="ssh -vvv" 复现，避免 OpenSSH 与 Git 内置环境混用。
Long-tail SEO
你可能正在搜索这些报错
下面这些错误原文、场景词和中英文搜索词，都是排查同类问题时常见的入口。
- SSH Permission denied publickey
- ssh -vvv publickey denied
- authorized_keys 权限错误
- GitHub Permission denied publickey
- ssh 指定 key 仍然失败
- Too many authentication failures ssh
- Windows Git SSH publickey 失败
- sshd authorized_keys 不生效
Need More Help
这个问题还没完全解决？
把你的报错、环境和已经尝试过的步骤发给我，后续会优先补充到排障手册。