认证次数超限是怎么来的
SSH 客户端会按顺序尝试认证方式和密钥：如果 ssh-agent 或默认目录里加载了大量密钥，客户端会逐个试过去，服务端在超过 MaxAuthTries 后直接断开，报 Too many authentication failures。也就是说这不是口令错误，而是「试得太多次」。正确的处理方向是让客户端明确只用一个密钥，而不是放宽服务端限制。
基本信息
| 报错原文 | Too many authentication failures |
|---|---|
| 根因 | 客户端逐个尝试多个密钥，超过服务端 MaxAuthTries |
| 客户端参数 | IdentitiesOnly=yes、-i 指定私钥 |
| 服务端参数 | sshd_config 中的 MaxAuthTries |
| 权限要求 | 调整服务端配置需 root |
典型使用场景
- 管理机上配了多个密钥，登录某台服务器时被直接拒绝
- 图形环境的密钥环自动加载大量密钥后 SSH 开始报错
- 同一账号能登录 A 服务器却登不上 B 服务器
- 自动化脚本因密钥过多导致连接不稳定
- 判断当前报错是口令错误还是认证次数超限
客户端处理
客户端处理
ssh-add -l # 查看 agent 已加载的密钥数量
ssh-add -D # 清空 agent，用于验证根因
ssh -v -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 user@host # -v 观察认证尝试顺序
ssh -o PreferredAuthentications=publickey -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 user@host
# 长期做法：写入 ~/.ssh/config 按主机固定
# Host app-*
# IdentityFile ~/.ssh/id_ed25519
# IdentitiesOnly yes
sshd -T | grep -i maxauthtries # 服务端当前生效值关键信息判读
| 信息来源 | 看什么 | 结论 |
|---|---|---|
| 报错文本 | Too many authentication failures | 认证次数超限，不是口令错误 |
| ssh -v 输出 | 依次尝试了哪些密钥 | 确认是否试了很多无关密钥 |
| ssh-add -l | agent 中已加载的密钥数量 | 数量多时优先怀疑这一项 |
| sshd -T | MaxAuthTries 的实际值 | 服务端限制过严也会触发 |
调大服务端 MaxAuthTries 等于放宽防爆破限制：优先在客户端精确指定密钥（IdentitiesOnly=yes 加 IdentityFile）把尝试次数压下来。
把 IdentityFile 按主机分组写进 ~/.ssh/config 是最省事的长期方案，登录时不用每次手工加参数，也能避免脚本踩同一个坑。
判别要点：如果 ssh -v 输出里能看到客户端连续尝试了多个密钥之后才被断开，就属于次数超限；如果第一个密钥报 Permission denied 再重试口令，那才是密钥或口令本身的问题。