SSH连接异常深度排障：KEX协商失败与认证静默拒绝解析

1. 这不是网络问题，是SSH协议在对你“说话”

“SSH连接异常”这六个字，几乎每个运维、开发、DevOps工程师都见过——但90%的人第一反应是：重启网络、换端口、ping一下服务器、查防火墙。我做过三年SRE，带过十几人团队，也亲手排查过200+起SSH连接失败案例。直到去年一个凌晨三点的线上事故让我彻底改观：一台生产数据库服务器SSH突然拒绝所有新连接，ssh -v输出停在debug1: SSH2_MSG_KEXINIT sent就卡死，而sshd进程明明在跑、CPU和内存正常、systemctl status sshd显示active (running)……我们花了47分钟才定位到根因——不是OpenSSH配置错，不是SELinux策略拦，甚至不是TCP连接被丢弃。真正的问题藏在SSH密钥交换阶段的算法协商失败里，而触发条件，是一次无人知晓的系统自动更新悄悄把OpenSSH从8.9p1升到了9.0p1，同时禁用了旧版DH-GEX密钥交换机制，而客户端（一台老旧的macOS 10.15机器）压根不支持新协商流程。

这就是“SSH连接异常”最危险的地方：它表面是连不上，底层却可能是协议演进、密码学迁移、系统兼容性断层、甚至内核参数级的隐性限制。它不像HTTP 500那样有明确错误码，也不像磁盘满那样有直观告警。它沉默、模糊、高度上下文依赖——你必须听懂SSH在“说什么”，而不是只看它“没说什么”。本文不讲“如何用ssh-keygen生成密钥”这种入门操作，而是聚焦真实生产环境中那些让你翻遍日志、抓包半小时、怀疑人生却仍无头绪的SSH连接异常场景。核心关键词：SSH连接卡顿、KEXINIT阻塞、Connection refused但端口通、Authentication refused但密码正确、sshd日志无记录、ssh -v输出中断位置分析、OpenSSH版本兼容性断层、密钥交换算法协商失败、sshd_config中未被重视的Subsystem与MaxStartups联动效应。适合已能熟练使用ssh -i、ssh-copy-id、sshd -t的中级以上从业者，尤其适合常驻Linux服务器环境、需高频远程管理多代异构系统的运维、SRE、安全工程师及嵌入式设备维护人员。

2. 卡在KEXINIT：当密钥交换成了“语言不通”的现场

绝大多数SSH连接异常，并非发生在认证环节，而是死在了连接建立后的第一步——密钥交换（Key Exchange, KEX）。这是SSH协议V2的核心安全基石：客户端与服务端必须先协商出一套双方都支持的加密算法、密钥交换方法、消息认证码（MAC）和压缩算法，才能进入后续的用户认证与会话加密。一旦协商失败，连接就会静默终止，且往往不留下任何有效日志线索。ssh -v输出中那句debug1: SSH2_MSG_KEXINIT sent，就是客户端发出的“协商邀请函”；如果服务端没回SSH2_MSG_KEXINIT，或者回了但客户端无法解析，连接就卡在这里。

2.1 为什么KEXINIT会卡住？三类典型断层

我将真实踩过的坑归为三类“断层”，它们共同特点是：服务端和客户端对“可用算法列表”的认知完全错位。

第一类：OpenSSH大版本升级引发的算法淘汰断层
OpenSSH 8.8（2021年9月发布）开始默认禁用ssh-rsa签名算法（基于SHA-1），8.9进一步移除diffie-hellman-group1-sha1和diffie-hellman-group14-sha1。而很多老旧设备（如某些网络设备的SSH客户端、Windows 7自带的OpenSSH 7.6、甚至部分IoT固件）仍硬编码只支持这些已被淘汰的算法。现象是：ssh -v user@host输出停在SSH2_MSG_KEXINIT sent，tcpdump -i any port 22能看到SYN/SYN-ACK/ACK三次握手完成，但之后只有客户端发的KEXINIT包，服务端零响应。这不是防火墙拦截（因为TCP连接已建立），而是sshd进程在收到KEXINIT后，遍历自身支持的算法列表，发现客户端提议的所有算法均被策略禁用，于是直接丢弃该连接，连sshd日志都不写——因为它连“尝试认证”这一步都没走到。

第二类：sshd_config中KexAlgorithms显式配置不当
有些安全加固文档会建议管理员手动收紧/etc/ssh/sshd_config中的KexAlgorithms，例如只保留ecdh-sha2-nistp256,ecdh-sha2-nistp384。这本身没问题，但若未同步检查客户端能力，就会导致兼容性灾难。更隐蔽的是：KexAlgorithms配置项不支持通配符或正则，必须精确列出所有允许的算法名，且顺序无关。我曾遇到一个案例：管理员为启用FIPS模式，在sshd_config中添加了KexAlgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521，却忘了FIPS模式下curve25519-sha256默认被禁用，而新版OpenSSH客户端（8.9+）默认优先尝试curve25519-sha256。结果就是客户端发KEXINIT时第一个提议curve25519-sha256，服务端一看不在白名单里，直接拒收，不给任何反馈。

第三类：内核级TCP参数与KEX超时的隐性冲突
KEX阶段虽短，但涉及非对称加密计算（如ECDH点乘），在低配设备（如树莓派、ARM嵌入式板）上可能耗时数百毫秒。而Linux内核的net.ipv4.tcp_fin_timeout（默认60秒）和net.ipv4.tcp_keepalive_time（默认7200秒）看似无关，实则影响深远。更关键的是/proc/sys/net/ipv4/tcp_synack_retries（默认5次）——它控制SYN-ACK重传次数。当KEX计算慢导致首次KEXINIT响应延迟超过tcp_rmem缓冲区等待阈值（通常200~500ms），客户端可能因未及时收到服务端KEXINIT响应而重发SYN，触发内核重传逻辑，最终在客户端侧表现为“Connection timed out”，而服务端sshd日志里连连接记录都没有，因为连接尚未完成三次握手后的应用层握手。

2.2 实战诊断：三步锁定KEX断层

要破局，必须绕过sshd日志的“失语”，直接捕获协议层真相。以下是我在生产环境反复验证的三步法：

第一步：强制客户端降级，验证是否为算法断层
不用猜，直接用ssh -o KexAlgorithms=+diffie-hellman-group14-sha1 -v user@host（OpenSSH 8.8+需加+号启用已禁用算法）。如果此时连接成功，说明100%是KEX算法不匹配。再用ssh -Q kex分别在客户端和服务端运行，对比输出的算法列表，找出交集缺失项。注意：ssh -Q kex输出的是本机OpenSSH编译时支持的算法，不代表当前sshd_config启用的算法，后者需结合配置文件判断。

第二步：服务端抓包，确认KEXINIT是否被接收与响应
在服务端执行：sudo tcpdump -i any -nn -s 0 port 22 -w ssh_kex.pcap，然后从客户端发起连接。停止抓包后用Wireshark打开，过滤ssh && ssh.kexinit。关键看两点：

• 客户端是否发送了SSH2_MSG_KEXINIT（Packet Details里Protocol > SSH > Message Type = 20）；
• 服务端是否返回了SSH2_MSG_KEXINIT（Message Type = 20）或SSH2_MSG_DISCONNECT（Message Type = 1）。
  如果只看到客户端发，服务端无任何SSH层响应，说明sshd进程根本没处理该连接——极可能是MaxStartups限流、ListenAddress绑定错误，或sshd被SIGSTOP挂起。

第三步：启用sshd调试日志，直击协商失败瞬间
临时修改/etc/ssh/sshd_config，添加两行：

LogLevel DEBUG3 SyslogFacility AUTHPRIV

然后sudo systemctl reload sshd（注意不是restart，避免中断现有连接）。此时/var/log/secure或/var/log/auth.log会输出海量细节。重点搜索kex、algorithm、negotiate等关键词。你会看到类似：

debug3: receive packet: type 20 debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none debug3: kex_choose_conf: cannot match kex algorithm

最后一行就是判决书——它明确告诉你，服务端在匹配KEX算法时失败了。

提示：DEBUG3日志量极大，仅用于临时诊断。生产环境切勿长期开启，否则日志文件会迅速膨胀至GB级，且可能暴露敏感信息（如密钥指纹）。

3. “Connection refused”背后的三重幻觉：端口通≠服务可连

ssh: connect to host x.x.x.x port 22: Connection refused——这个报错堪称SSH领域最经典的“幻觉制造者”。它让无数人第一时间冲向防火墙、iptables、云安全组，却忽略了更底层的三个真相：sshd监听地址错配、systemd socket激活失败、以及sshd进程被OOM Killer干掉后留下的“僵尸监听”。

3.1 幻觉一：端口监听了，但sshd根本没在听你的IP

netstat -tlnp | grep :22或ss -tlnp | grep :22显示0.0.0.0:22或*:22，你以为万事大吉？错。OpenSSH的ListenAddress配置项可以精确指定sshd监听的IP地址。默认配置通常是ListenAddress 0.0.0.0:22（监听所有IPv4地址），但若管理员为安全考虑改为ListenAddress 192.168.1.100:22，那么从公网IP或另一网段（如10.0.0.5）发起的连接，即使22端口在netstat里显示“监听”，也会得到Connection refused——因为sshd根本没在那个IP上开监听套接字。

更隐蔽的是IPv6陷阱。现代Linux发行版默认启用IPv6，sshd_config中若未显式配置ListenAddress，sshd会同时监听IPv4的0.0.0.0:22和IPv6的[::]:22。但某些云平台（如AWS EC2）的实例，其公网IPv4地址和私有IPv6地址并不互通。当你用ssh user@ec2-xx-xx-xx-xx.compute-1.amazonaws.com连接时，DNS可能返回A记录（IPv4）和AAAA记录（IPv6），而OpenSSH客户端默认优先尝试IPv6。如果服务端的IPv6地址未正确配置路由或防火墙放行，客户端就会收到Connection refused，而netstat -tlnp | grep :22却显示[::]:22正在监听——因为IPv6监听套接字确实存在，但它无法响应来自公网的IPv6请求。

验证方法极其简单：

• ssh -4 user@host强制IPv4，ssh -6 user@host强制IPv6，对比结果；
• ss -tlnp 'sport = :22'查看具体监听的IP和端口，确认是否包含你期望的地址；
• 检查/etc/ssh/sshd_config中ListenAddress是否被注释或误配。

3.2 幻觉二：systemd socket激活“假在线”

在CentOS 8+/RHEL 8+、Fedora、Ubuntu 20.04+等采用systemd的系统中，OpenSSH默认以socket激活方式运行：sshd.socket负责监听22端口，sshd.service按需启动。这种设计节省资源，但带来一个致命隐患：sshd.socket可能处于active状态，而sshd.service从未被触发启动，或启动后崩溃退出，但socket仍“假装在线”。

现象是：systemctl status sshd.socket显示active (listening)，ss -tlnp | grep :22也显示监听，但systemctl status sshd.service却是inactive (dead)。此时任何SSH连接都会得到Connection refused，因为socket虽然开着，但背后没有sshd进程来处理连接。

原因常见于：

• sshd_config语法错误，导致sshd -t校验失败，sshd.service启动时立即退出；
• sshd.service的Restart=策略未配置（如Restart=on-failure），进程崩溃后不自启；
• LimitNOFILE等资源限制过低，sshd启动时因无法分配足够文件描述符而失败。

诊断命令链：

# 1. 确认socket状态 systemctl status sshd.socket # 2. 确认service状态（注意：即使socket active，service也可能dead） systemctl status sshd.service # 3. 查看socket激活日志（关键！） journalctl -u sshd.socket -n 50 --no-pager # 4. 手动触发一次连接，看service是否被激活 sudo systemctl start sshd.socket # 确保socket启动 ssh -o ConnectTimeout=5 user@localhost # 本地测试，触发激活 systemctl status sshd.service # 此时应变为active (running)

修复方案：

• 若sshd_config有误，先sudo sshd -t校验并修正；
• 在/etc/systemd/system/sshd.service.d/override.conf中添加：

  [Service] Restart=on-failure RestartSec=10 LimitNOFILE=65536

• 重载配置：sudo systemctl daemon-reload && sudo systemctl restart sshd.socket

3.3 幻觉三：OOM Killer的“幽灵监听”

这是最反直觉的场景。某天你发现sshd进程莫名消失，systemctl status sshd显示failed，但ss -tlnp | grep :22依然显示LISTEN，且lsof -i :22找不到对应PID。连接时却报Connection refused。这极可能是Linux OOM Killer（Out of Memory Killer）的杰作。

当系统内存严重不足时，OOM Killer会根据oom_score_adj值选择进程杀死。sshd进程（尤其是处理大量连接时）内存占用可能飙升，成为目标。但OOM Killer杀死进程后，该进程之前创建的监听套接字（socket）并不会立即从内核中清除——它会残留一段时间，表现为ss命令仍能看到LISTEN状态，但已无进程关联。此时任何新连接都会被内核直接拒绝，返回Connection refused。

验证方法：

• dmesg -T | grep -i "killed process"查看OOM事件时间戳；
• grep -i "out of memory" /var/log/messages或journalctl -b | grep -i "oom"；
• cat /proc/sys/vm/oom_kill_disable确认OOM Killer未被禁用（通常为0，表示启用）。

解决思路：

• 短期：sudo systemctl restart sshd强制重建监听套接字；
• 长期：调整sshd的内存限制，或优化系统内存使用。在/etc/systemd/system/sshd.service.d/override.conf中添加：

  [Service] MemoryLimit=512M OOMScoreAdjust=-500

  OOMScoreAdjust=-500大幅降低sshd被OOM Killer选中的概率（范围-1000到1000，越低越不易被杀）。

注意：OOMScoreAdjust值需谨慎设置。设为-1000可完全禁止OOM Killer杀该进程，但可能导致系统因内存耗尽而完全卡死。-500是兼顾安全与稳定的经验值。

4. 认证环节的“无声谋杀”：Authentication refused的七种死法

当SSH连接成功建立（ssh -v能看到debug1: Authentication succeeded或至少走到debug1: Next authentication method: password），却卡在认证环节，报Permission denied (publickey,gssapi-keyex,gssapi-with-mic)或Authentication refused，这比KEX阶段更令人抓狂——因为日志里往往有记录，但线索支离破碎。我梳理出七种最常被忽略的“死法”，每一种都源于对SSH认证流程的某个关键环节理解偏差。

4.1 死法一：AuthorizedKeysCommand的权限地狱

OpenSSH支持通过AuthorizedKeysCommand指令，让sshd动态调用外部脚本获取公钥。这很酷，但权限模型极其严苛：该脚本及其所有父目录，对root以外的任何用户（包括sshd运行的sshd用户）都不能有写权限。即：脚本路径/usr/local/bin/get-keys.sh，要求/usr、/usr/local、/usr/local/bin、/usr/local/bin/get-keys.sh所有层级的目录和文件，other和group的w权限必须为0。

违反此规则的后果是：sshd在调用脚本前会进行严格检查，一旦发现任意一级有写权限，就直接跳过该指令，不执行脚本，也不报错，只是默默回到默认的~/.ssh/authorized_keys查找——而如果你的公钥只存在脚本返回结果里，认证必然失败。/var/log/secure里只会有一行Failed publickey for user from x.x.x.x port xxxxx ssh2: RSA SHA256:xxx，毫无提示。

验证方法：

# 检查脚本路径每一级的权限 namei -l /usr/local/bin/get-keys.sh # 输出示例： # f: /usr/local/bin/get-keys.sh # dr-xr-xr-x root root / # drwxr-xr-x root root usr # drwxr-xr-x root root local # drwxr-xr-x root root bin # -r-xr-xr-x root root get-keys.sh # 注意：所有行的group和other列都不能出现`w`

修复：sudo chmod 755 /usr/local /usr/local/bin && sudo chmod 755 /usr/local/bin/get-keys.sh（确保无w）。

4.2 死法二：SELinux的“隐形手铐”

在RHEL/CentOS/Fedora等启用SELinux的系统上，sshd进程运行在system_u:system_r:sshd_t:s0域下。它默认不允许读取用户主目录外的authorized_keys文件。如果你为了集中管理，将公钥放在/etc/ssh/keys/user.pub，并在sshd_config中配置AuthorizedKeysFile /etc/ssh/keys/%u.pub，那么即使文件权限644、属主正确，认证也会失败——因为sshd_t域无权访问/etc/ssh/keys/目录（该目录默认标签为system_u:object_r:etc_t:s0）。

现象：ssh -v显示debug1: Offering public key: /path/to/key RSA SHA256:xxx，服务端日志/var/log/secure有Failed publickey for user...，但无SELinux拒绝记录（因为默认不记录dontaudit规则）。

验证：

• 临时禁用SELinux：sudo setenforce 0，再试连接。若成功，则100%是SELinux问题；
• 检查SELinux审计日志：sudo ausearch -m avc -ts recent | grep sshd；
• 查看/var/log/audit/audit.log中是否有avc: denied条目。

修复：

• 方案A（推荐）：为/etc/ssh/keys/目录打上正确标签：

  sudo semanage fcontext -a -t ssh_home_t "/etc/ssh/keys(/.*)?" sudo restorecon -Rv /etc/ssh/keys/

• 方案B：修改sshd_config，将AuthorizedKeysFile指向~/.ssh/authorized_keys（默认路径），避免跨域访问。

4.3 死法三：PAM模块的“静音拦截”

/etc/pam.d/sshd是SSH认证的“闸门控制器”。其中auth [default=ignore success=ok] pam_succeed_if.so user ingroup nopasswdlogin这类规则，若配置不当，会在用户属于某组时直接跳过密码认证，但又不提供替代路径，导致Authentication refused。

更常见的是pam_faildelay.so或pam_tally2.so（RHEL7）/pam_faillock.so（RHEL8+）的暴力防护模块。当用户连续输错密码超过阈值（如5次），模块会将该用户加入黑名单，并在后续所有认证请求中直接返回失败，且不记录到/var/log/secure——因为失败发生在PAM层，sshd进程甚至没机会记录。

验证：

• sudo faillock --user username（RHEL8+）或sudo pam_tally2 --user username（RHEL7）查看失败计数；
• sudo faillock --user username --reset（RHEL8+）或sudo pam_tally2 --user username --reset（RHEL7）重置计数。

修复：

• 调整/etc/security/faillock.conf或/etc/pam.d/common-auth中相关PAM模块的deny、unlock_time参数；
• 或临时注释/etc/pam.d/sshd中相关行进行测试。

4.4 死法四：sshd_config中UsePAM与PasswordAuthentication的“逻辑悖论”

sshd_config中UsePAM yes和PasswordAuthentication yes看似相容，实则暗藏冲突。当UsePAM yes启用时，PasswordAuthentication的值会被PAM配置覆盖。即：即使你在sshd_config中写了PasswordAuthentication yes，如果/etc/pam.d/sshd中对应的auth堆栈里没有pam_unix.so或pam_succeed_if.so等允许密码认证的模块，密码认证依然会失败。

现象：ssh -v显示debug1: Next authentication method: password，输入密码后卡住几秒，然后报Permission denied, please try again.，/var/log/secure无密码错误记录，只有Failed password for user...。

验证：

• sudo sshd -T | grep -E "(usepam|passwordauthentication)"查看sshd实际加载的配置；
• 检查/etc/pam.d/sshd中auth行是否包含pam_unix.so（标准Unix密码认证）。

修复：

• 确保/etc/pam.d/sshd中有：auth [success=done new_authtok_reqd=done default=bad] pam_unix.so；
• 或在sshd_config中显式设UsePAM no，让PasswordAuthentication直接生效（但会失去PAM提供的其他功能，如密码强度检查、账户锁定等）。

4.5 死法五：MaxAuthTries的“温柔一刀”

sshd_config中的MaxAuthTries默认值为6，它限制单个连接会话中允许的认证尝试总次数（包括publickey、password、keyboard-interactive等所有方法）。当用户配置了多个密钥（如~/.ssh/config中IdentityFile指定了3个），而前两个都无效时，ssh客户端会依次尝试，直到MaxAuthTries耗尽，然后报Authentication refused，且不提示具体原因。

验证：

• sudo sshd -T | grep maxauthtries查看当前值；
• ssh -v输出中观察debug1: Next authentication method:的切换次数。

修复：

• 增加MaxAuthTries值（如MaxAuthTries 10），但需权衡暴力破解风险；
• 更优解：清理~/.ssh/config中无效的IdentityFile，或在连接时用-i /path/to/valid_key显式指定。

4.6 死法六：ChrootDirectory的“权限迷宫”

为安全隔离，常配置ChrootDirectory /chroot/%u。但chroot环境有严苛要求：ChrootDirectory路径及其所有父目录，必须由root拥有，且不能有group或other的写权限。即/chroot、/chroot/username都必须是root:root，且权限为755或750（不能是775或777）。

违反时，sshd在chroot前会检查，失败则直接拒绝认证，日志中只有fatal: bad ownership or modes for chroot directory component，但客户端看到的仍是Authentication refused。

验证：

ls -ld /chroot /chroot/username # 必须输出类似： # drwxr-xr-x. 3 root root 4096 Jan 1 00:00 /chroot # drwxr-xr-x. 3 root root 4096 Jan 1 00:00 /chroot/username

修复：

sudo chown root:root /chroot /chroot/username sudo chmod 755 /chroot /chroot/username

4.7 死法七：GSSAPIAuthentication的“Kerberos幽灵”

GSSAPIAuthentication yes启用Kerberos认证。当客户端发送GSSAPI请求，但服务端Kerberos配置错误（如/etc/krb5.conf域名不匹配、keytab文件不存在或损坏），sshd会尝试处理但失败，然后静默跳过GSSAPI，继续尝试下一个方法。但如果下一个方法（如publickey）也失败，最终报Authentication refused，而日志里可能只有GSSAPI error的模糊提示。

验证：

• ssh -v -o GSSAPIAuthentication=no user@host禁用GSSAPI，看是否成功；
• klist -k /etc/krb5.keytab检查keytab是否有效。

修复：

• 若无需Kerberos，sshd_config中设GSSAPIAuthentication no；
• 若需Kerberos，确保/etc/krb5.conf正确，kinit -k -t /etc/krb5.keytab host/hostname@REALM能成功获取票据。

5. 终极武器库：五个不可替代的诊断与修复工具

面对千奇百怪的SSH连接异常，光靠ssh -v和journalctl远远不够。以下是我在五年高强度排障中沉淀出的五个“不可替代”工具，它们不一定是官方推荐，但在特定场景下，效率碾压一切。

5.1 sshd -d：单进程调试模式——让sshd自己“开口说话”

sshd -d（debug mode）是OpenSSH内置的终极调试开关。它让sshd以单进程、前台模式运行，不fork子进程，所有日志直接输出到终端，且级别为DEBUG2（比LogLevel DEBUG3更底层，包含内存分配、信号处理等细节）。

适用场景：当sshd启动即失败、systemctl status sshd只显示failed无日志、或DEBUG3日志仍无法定位时。

操作步骤：

1. 停止现有sshd：sudo systemctl stop sshd；
2. 备份配置：sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak；
3. 启动调试模式：sudo /usr/sbin/sshd -d -p 2222（-p 2222指定临时端口，避免冲突）；
4. 从另一终端连接：ssh -p 2222 user@localhost；
5. 观察前台sshd -d输出的每一行，它会详细打印：
   • 配置文件加载路径与解析过程；
   • 监听套接字创建与绑定详情；
   • 每个连接的完整生命周期（accept → kex → auth → session）；
   • 内存分配失败、文件打开错误等底层异常。

关键优势：绕过systemd日志缓冲、绕过syslog过滤、绕过sshd守护进程模型，直击问题源头。我曾用它在一分钟内定位到sshd_config中一个隐藏的UTF-8 BOM字符导致sshd -t校验通过但sshd -d启动失败。

5.2 ssh-audit：算法合规性“CT扫描仪”

ssh-audit是一个Python工具，专为SSH协议安全审计设计。它不模拟连接，而是主动向目标SSH服务发送KEXINIT请求，解析服务端返回的算法列表，并对照NIST、CNSA、PCI-DSS等标准，给出合规性评分与风险建议。

安装与使用：

pip3 install ssh-audit ssh-audit 192.168.1.100:22

输出示例：

# general (gen) banner: SSH-2.0-OpenSSH_9.0p1 Debian-1 (gen) software: OpenSSH 9.0p1 (gen) compatibility: OpenSSH 6.5+, Dropbear SSH 2013.62+ (gen) connection: unexpected failure (timeout) # key exchange algorithms (kex) (kex) curve25519-sha256 -- [warn] available since OpenSSH 7.4, but not in OpenSSH 7.5-7.7 (kex) ecdh-sha2-nistp256 -- [info] available since OpenSSH 5.7, Dropbear SSH 0.53 (kex) diffie-hellman-group14-sha256 -- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73 (kex) diffie-hellman-group16-sha384 -- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73 (kex) diffie-hellman-group18-sha512 -- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73 (kex) diffie-hellman-group-exchange-sha256 -- [fail] removed in OpenSSH 8.9, Dropbear SSH 2018.76

价值：它把抽象的“算法兼容性”转化为可读的[fail]/[warn]/[info]标签，让你一眼看出服务端是否启用了已淘汰算法（如diffie-hellman-group-exchange-sha256），或缺少必要算法（如curve25519-sha256）。比手动ssh -Q kex高效十倍。

5.3 ss + bpftrace：内核级连接追踪

当tcpdump抓不到包、ss看不到连接状态时，说明问题已深入内核网络栈。此时bpftrace（eBPF工具）是唯一选择。

场景：ss -tlnp | grep :22显示监听，telnet host 22能连上（证明TCP层通），但ssh连接卡死。怀疑是sshd进程未accept()连接，或连接被内核丢弃。

bpftrace脚本（监控sshd accept调用）：

sudo bpftrace -e ' kprobe:sys_accept { if (comm == "sshd") { printf("sshd accept() called at %s\n", strftime("%H:%M:%S", nsecs)); } } uprobe:/usr/sbin/sshd:accept { printf("sshd uprobe accept() at %s\n", strftime("%H:%M:%S", nsecs)); }'

解读：

• 若kprobe有输出但uprobe无输出，说明sshd进程收到了SYN，但未调用accept()系统调用——极可能是MaxStartups限流或sshd被挂起；
• 若两者都无输出，说明连接在到达sshd前就被内核丢弃（如net.ipv4.tcp_abort_on_overflow=1且listen()队列满）。

优势：实时、精准、无侵入，直接观测内核与用户态交互，是strace的超集。

5.4 sshrc：连接后的“环境手术刀”

sshrc是一个小众但神级的工具，它允许你在SSH登录成功后，自动执行一段本地shell脚本，从而动态修复环境问题。它不解决连接异常本身，但能解决“连接成功后无法工作”的衍生问题。

典型用例：

• 连接到一台老旧服务器，bash版本太低不支持[[ ]]，而