Auth 失败总是让人头大？教你几招快速排查和解决

折腾服务器或者各种服务的时候，最让人抓狂的瞬间之一，绝对莫过于屏幕上冷冰冰地弹出一行 “Auth failed”（认证失败）。这时候，你是会怀疑人生，觉得自己是不是把密码忘了？还是会觉得是服务器在针对你？

其实，遇到这种情况别慌，绝大多数情况下都不是你的“人品”问题，而是某个具体的配置环节出了岔子。今天咱们就来以此为切入点，像老朋友聊天一样，好好盘一盘遇到 Auth 失败时，我们该从哪里下手排查，怎么快速搞定它。

既然是“认证失败”，那最直接的原因就是凭证不对。就像是你拿着错误的钥匙去开家门，门肯定打不开。

大小写和特殊字符 很多时候，我们在本地复制密码，可能会不小心多复制了一个空格，或者 Caps Lock 键处于开启状态导致大小写错误。尤其是那些强密码，包含各种 !@#$%^&*，输入法稍微切错一下，意思就全变了。
- 建议：不要手动输入，尝试使用密码管理器直接粘贴，或者先把密码粘贴到记事本里，看看首尾有没有多余的空格。
用户名是不是搞错了？ 这是一个高频盲区。很多新手（甚至老手）在 SSH 连接时，习惯性输入 root，但有些服务器为了安全，默认禁用了 root 登录，或者你购买的新 VPS 默认用户其实是 ubuntu、admin 或者其他名字。
- 建议：确认一下你的连接命令。是 ssh root@ip 还是 ssh user@ip？翻翻购买邮件里的初始化信息，通常都有明确说明。

现在为了方便和安全，很多朋友都习惯用 SSH 密钥登录。如果密钥报 Auth 失败，排查起来比密码稍微复杂一点，但也有迹可循。

权限问题（最常见！） Linux 对文件权限非常敏感。如果你的私钥文件权限太宽（比如比如 777），SSH 客户端会直接判定为不安全而拒绝使用。
- 解决办法：在终端里执行 chmod 400 你的秘钥文件名.pem，确保只有所有者有读权限。
公钥没放对地方 你在服务器端 ~/.ssh/authorized_keys 文件里添加公钥了吗？或者是不是 append 追加的时候覆盖了原来的内容？又或者这个文件的权限也设置错了（通常需要 600 或 644）？
- 解决办法：登录服务器（如果还能用密码登的话），检查 ~/.ssh/ 目录和 authorized_keys 文件的权限是否正确。
代理转发或者 Agent 问题 有时候你本地有多个 Key，服务器不知道该用哪个去匹配。
- 解决办法：尝试在 SSH 命令里加参数指定秘钥，例如 ssh -i /path/to/your/key user@ip，这样可以排除到底是不是用了错误的 Key 文件。

如果你确信账号密码没问题，Key 也没问题，那可能是服务器“变心”了，调整了安全策略。

账号被锁定 如果你连续输错多次密码，服务器为了防爆破，可能会暂时锁定你的 IP 或者账号。这就像银行卡输错三次密码被冻结一样。
- 解决办法：如果是云服务器，尝试去网页控制台的 VNC 登录（这个不走网络，不受 IP 限制），进去查看 /var/log/auth.log（Debian/Ubuntu）或者 /var/log/secure（CentOS），看看有没有具体的报错记录。
SSH 配置文件被改过 检查一下 /etc/ssh/sshd_config 文件。是不是有人把 PasswordAuthentication 改成了 no（这就强制只能用 Key 登录了）？或者 PermitRootLogin 被改成了 no（禁止 Root 登录）？
- 解决办法：如果改了配置，记得重启 sshd 服务 (systemctl restart sshd)。

还有一种可能，问题不在你，也不在服务器，而在中间链路。

中间人攻击（虽然少见但要注意）：如果 StrictHostKeyChecking 提示指纹不对，千万别硬连，这可能是 DNS 劫持或者路由出了问题。
客户端版本太旧：极少数情况下，服务器升级了加密算法，老旧的 SSH 客户端不支持，也会导致握手失败报 Auth 错误。试着升级一下你本地的 SSH 工具或者换一个终端软件（比如从 Xshell 换到 Termius 或 FinalShell 试试）。

下次再遇到 Auth Failed，别先急着怀疑人生。按照这个顺序排查：

技术问题大抵如此，看起来可怕，只要抽丝剥茧，往往都是某个小细节在作祟。希望这篇碎碎念能帮你下次少走点弯路，早日恢复服务器的通畅！