SSH提示kex_exchange_identification，连接被关闭的定位教程

SSH连接刚开始就提示 kex_exchange_identification: Connection closed by remote host，说明连接在密钥交换或更早阶段被关闭。故障通常发生在用户密码或公钥认证之前，反复更换authorized_keys往往没有作用。

应先确认请求是否真正到达sshd，再检查未认证连接限流、安全封禁和端口转发，而不是直接放宽全部SSH安全配置。

从客户端详细日志确认断点

使用详细模式重试，并明确目标端口：

ssh -vvv -p 22 user@server.example.com

若日志显示TCP连接已经建立，随后在收到服务端版本字符串或密钥交换信息前关闭，问题更可能位于服务端sshd、访问控制或中间设备。若连TCP都无法建立，应优先检查安全组、防火墙、端口和路由。

nc -vz server.example.com 22

不要把Connection timed out、Connection refused和kex_exchange_identification混成同一种故障。 三者发生位置不同，处理方向也不同。

保留云控制台或其他已登录会话，在服务端观察日志：

sudo journalctl -u ssh -u sshd --since "10 minutes ago" --no-pager
sudo systemctl status ssh 2>/dev/null || sudo systemctl status sshd

Debian和Ubuntu服务名常为 ssh，RHEL系常为 sshd。日志若完全没有本次客户端IP，说明连接可能在云防火墙、主机防火墙、NAT或代理层被丢弃。日志出现preauth、MaxStartups或封禁信息时，再针对该组件处理。

任何配置改动前先运行 sudo sshd -t，并保持当前管理会话不要退出。

OpenSSH的 MaxStartups 限制同时存在的未认证连接。查看当前生效值：

sudo sshd -T | grep -E '^(maxstartups|persourcemaxstartups|logingracetime)'

OpenSSH官方默认 MaxStartups 10:30:100，表示达到10个未认证连接后开始按概率拒绝，达到100个时全部拒绝。新版本还可用 PerSourceMaxStartups 限制单一来源。

在遭遇扫描、客户端连接风暴或自动化任务大量并发时，正常用户也可能被提前断开。不能只为消除报错就无限调高MaxStartups，应先限制扫描来源并修复并发连接行为。

检查客户端公网IP是否进入Fail2ban或防火墙集合：

sudo fail2ban-client status sshd 2>/dev/null
sudo nft list ruleset | less
sudo iptables -S

不同发行版可能使用nftables、iptables或云平台安全组。确认属于误封后，按照当前Fail2ban版本提供的解封命令处理，并修正触发原因；不要直接停止整套防护。

若服务器经过负载均衡、端口转发或堡垒机，还要确认sshd看到的来源IP是否正确。错误地把代理IP当成攻击来源，可能一次封掉所有经过该代理的管理员。

确认sshd实际监听地址和端口：

sudo ss -lntp | grep ssh
sudo sshd -T | grep -E '^(port|listenaddress)'

云平台把外部端口转发到内部22端口时，客户端 -p 必须使用外部端口。容器化sshd还要核对端口映射、宿主机监听和容器日志。

需要从不同网络复测时，可临时使用 萤光云 或 LightNode 建立独立测试端。复测机只用于确认路径，不要复制生产私钥。

确需调整sshd参数时，把变更写入发行版支持的配置文件或 sshd_config.d 片段，先检查语法再重载：

sudo sshd -t
sudo systemctl reload ssh 2>/dev/null || sudo systemctl reload sshd

另开终端完成一次新登录，再检查日志中没有持续的未认证连接堆积。只有新旧管理通道都确认可用后，才能关闭原会话。

这个错误一定是MaxStartups吗？

不一定。它只表示认证前连接被关闭，Fail2ban、防火墙、代理、sshd重启和资源不足都可能造成相似现象。

重启sshd能解决吗？

重启可能暂时清空连接，但会掩盖并发风暴或规则误封。应先保存日志与连接状态，优先使用配置检查和reload。

为什么只有一个办公网络连不上？

该出口IP可能被Fail2ban、每来源限流或云防火墙命中，也可能存在路径MTU或中间代理问题。可用另一个可信网络对比验证。

远程修改SSH前必须保留带外控制台或已验证的第二条登录通道。 不要通过关闭Fail2ban、清空整套防火墙或全局放宽sshd限制来换取短暂可用。