Linux SSH 连接卡在认证前：用 ssh -vvv 读懂密钥协商与服务端日志

终端里输入 ssh user@server 后，连接既没有提示密码，也没有明确报错，只停在几行握手信息上，最容易误判成“密钥不对”。先别急着换密钥：SSH 客户端会依次经历网络连接、密钥协商、主机密钥确认和用户认证，卡点不同，排查入口完全不同。

用 ssh -vvv 找到最后一个完成的阶段，再把这一行与服务端日志对上；只有确认已经进入用户认证，才值得检查 authorized_keys 或密码策略。

先把 SSH 卡点分成三段

这次只处理“认证提示出现以前”的停顿。可以把一次连接拆成三段：连接建立、密钥协商、用户认证。客户端的调试输出是时间线，排查时看“最后一条明确完成的事件”，不要只看最后一行。

例如，下面三行分别对应不同结论：

debug1: Connecting to server.example port 22.
debug1: Connection established.
debug1: Local version string SSH-2.0-OpenSSH_9.6

如果只有第一行，先查地址、路由和防火墙；如果已经出现第二行，TCP 三次握手已经完成，应把注意力移到 SSH 协议；如果还没出现服务器版本字符串，服务端可能没有正确响应 22 端口，或中间设备把连接接走了。

用 ssh -vvv 读出最后一个完成事件

先在客户端执行一次带目标地址的诊断命令，必要时加上连接超时，避免网络异常时一直等待：

ssh -vvv -o ConnectTimeout=10 user@server.example

不要把完整输出直接贴到公共工单里。调试信息可能包含用户名、主机名、代理跳转和本地路径；保留事件顺序即可。

停在连接建立之前

没有 Connection established，或者输出只停在 “Connecting to ... port 22”，这还不是密钥问题。先用 nc -vz server.example 22 验证端口，再核对 DNS 解析到的地址、云安全组和主机上的监听端口。若端口探测也失败，修改 ~/.ssh/config 里的算法列表不会带来任何帮助。

连接已建立但协商没有收敛

看到客户端和服务端版本字符串，却在 SSH2_MSG_KEXINIT 附近停住或报 “no matching ... found”，说明连接已经进入算法协商。此时把双方支持列表放在一起比较，重点看 KEX、主机密钥算法和 MAC，不要直接复制网上的“兼容旧服务器”整段配置。

ssh -Q kex
ssh -Q HostKeyAlgorithms
ssh -G user@server.example | sed -n '1,120p'

客户端的有效配置可由 ssh -G 展开；它能发现某个 Host 区块或跳板机配置是否覆盖了你以为正在使用的选项。服务端若是自己维护的，再检查 sshd -T 输出与实际配置文件是否一致。

出现认证方法列表才进入用户认证

当输出出现 Authentications that can continue: publickey,password，说明密钥协商已经完成，服务端正在告诉客户端可尝试的认证方法。此后再检查公钥权限、代理中的身份数量、密码策略和账号状态才有意义。若列表为空或服务端立即断开，结合服务端日志判断是策略拒绝还是账号被限制。

服务端日志如何与客户端时间线对齐

客户端告诉你“停在哪一步”，服务端日志帮助确认“为什么”。在 systemd 管理的发行版上，可先限定服务和最近时间范围：

sudo journalctl -u sshd --since "10 minutes ago" --no-pager
sudo journalctl -u ssh --since "10 minutes ago" --no-pager

不同发行版的服务名可能是 ssh 或 sshd，以本机实际单元为准。日志出现 no matching、Unable to negotiate，应继续查算法协商；若出现 Failed publickey 或 authentication failure，才转入用户认证。

只为一次复测提高日志等级

如果默认日志不足，可以在服务端配置中临时使用 LogLevel VERBOSE，先用配置检查命令确认语法，再重载服务并完成一次复测。OpenBSD 的 sshd_config(5) 将 LogLevel 分为 INFO、VERBOSE 和 DEBUG 等级；DEBUG 级别会带来更多敏感细节，不适合长期开启。

sudo sshd -t
sudo systemctl reload sshd
ssh -vvv -o ConnectTimeout=10 user@server.example
sudo journalctl -u sshd --since "2 minutes ago" --no-pager

复测完成后恢复原来的日志等级并再次执行 sshd -t。这里要看的是同一时间窗口内，客户端最后一条事件与服务端的拒绝原因能否对应起来。

按证据选择最小修复

比较工具或配置时，真正有用的维度不是“支持多少算法”，而是证据能否直接指导下一步：

• 端口探测失败：查网络路径、监听端口和访问控制。
• 算法无交集：只在明确知道双方版本和风险后，针对单个主机配置兼容项，并安排升级。
• 认证方法已出现：检查用户、密钥文件、代理身份和服务端认证策略。
• 服务端提前断开：优先看日志中的策略拒绝、连接限制或登录时间窗口。

修改前保存当前配置。尤其是算法列表，删除一项旧算法可能让另一批老客户端无法登录；临时放宽也不能替代升级计划。

常见问题

看到 Connection established 还需要查防火墙吗？

网络层至少已经建立到目标端口的 TCP 连接，但中间设备仍可能在后续阶段丢包。先继续看服务端版本字符串和日志，再决定是否回到网络层。

为什么 ssh -vvv 输出很多内容仍定位不了？

不要从头逐字阅读，先找最后一条阶段性事件，再用同一时间范围的服务端日志做交叉验证。脱敏后保留事件顺序，通常比整段日志更容易复盘。

可以直接在客户端加 HostKeyAlgorithms 解决吗？

只有在确认是主机密钥算法没有交集时才考虑。临时兼容项应限制在单个 Host 配置中，并记录回收条件，避免把旧算法扩散到所有服务器。

服务端改 LogLevel 会不会影响登录？

日志等级本身通常不改变认证策略，但 DEBUG 可能暴露更多敏感细节并增加日志量。优先使用一次性的 VERBOSE 复测，完成后恢复原值。

把下一次排查变成可复用清单

每次遇到“SSH 卡在认证前”，按连接建立、密钥协商、用户认证三段记录最后完成事件；同时保存客户端的有效配置摘要、服务端对应时间窗日志和唯一改动。这样下一次面对相同现象时，先判断层级，再选择工具，排查时间会明显缩短。