问题背景：为何SSH总会“突然”断开？
在IT基础设施维护工作中，远程管理是日常高频操作。然而，许多系统管理员或运维人员经常遇到一个棘手的问题：在使用SSH连接Linux服务器时，如果一段时间不进行任何操作（如查看进程、编辑配置），连接便会无故中断，终端返回 "Connection closed by remote host" 或 "Read from remote host ... Connection reset by peer"。
对于习惯使用GUI界面的开发者或新手而言，这往往令人困惑且沮丧，因为表面上看网络连接是正常的（`ping` 命令依然通）。但在企业级环境中，这种不稳定性可能导致未保存的工作丢失、长耗时脚本意外终止，甚至影响自动化部署流程的连续性。本文将深入剖析这一现象背后的技术原理，并提供系统的排查与解决方案。
根本原因分析：三层视角的断连逻辑
SSH连接的意外断开通常不是单一因素造成的，而是客户端、网络中间设备和服务器端三者对“空闲连接”定义不一致的结果。我们可以从以下三个层面来理解：
1. 网络中间设备（防火墙/NAT/负载均衡器）的超时策略
这是最常见的原因。企业网络边界通常部署有防火墙、NAT网关或硬件负载均衡器（如F5）。这些设备为了节省资源，会维护一张“会话表”（Session Table），记录所有活跃的连接状态。
TCP空闲超时机制：大多数防火墙默认设置了一个TCP空闲超时时间（Idle Timeout），通常在5分钟到30分钟之间。如果一条TCP连接在此时间内没有数据交互，防火墙会认为该连接已失效，并主动向两端发送RST（重置）包或丢弃后续数据包。当服务器尝试发送心跳或接收客户端数据时，发现连接已被静默关闭，从而引发SSH断开。
2. SSH服务端（sshd）的配置限制
OpenSSH守护进程（sshd）自身也有配置参数来控制客户端连接的生命周期。如果服务器管理员为了安全加固，关闭了 keepalive 检测或设置了较短的 `ClientAliveInterval`，服务器会在检测到客户端无响应时主动断开连接。
3. SSH客户端（如PuTTY, OpenSSH Client）的行为
默认的SSH客户端在空闲时不会主动发送任何数据包。这意味着，如果网络中间设备设置了超时，而客户端和服务端都保持沉默，防火墙就会成为“断头台”，切断这条看似活着但实际上已僵死的连接。
实战排查与解决方案
解决SSH断连问题，建议按照“从外到内，从简到繁”的顺序进行排查和调整。以下是具体的操作步骤。
第一步：确认是否为网络层干扰
在进行任何配置修改前，先判断断连是否由中间设备引起。你可以尝试在空闲期间，在终端执行简单的命令（如 `echo` 或 `uptime`），观察连接是否会断开。如果即使有操作也会偶尔断开，可能是网络波动；如果仅在长时间无操作后断开，则极大概率是防火墙超时所致。
第二步：配置SSH客户端发送心跳包（推荐方案）
这是最通用且无需修改服务器配置的方法。通过让客户端定期向服务器发送微小数据包，可以欺骗防火墙，使其认为该连接仍处于活跃状态，从而重置空闲计时器。
针对 OpenSSH (Linux/macOS)：
编辑用户家目录下的 `~/.ssh/config` 文件（若无则新建），添加以下内容：
Host *：表示对所有主机生效，也可替换为特定IP或别名。ServerAliveInterval 60：客户端每60秒向服务器发送一次心跳请求。ServerAliveCountMax 3：如果连续3次发送心跳无响应，才判定连接断开。
配置示例：
Host * ServerAliveInterval 60 ServerAliveCountMax 3
针对 PuTTY (Windows)：
在连接前的配置界面中：
- 进入 Connection 类别。
- 找到 Seconds between keepalives (0 to turn off) 选项。
- 将其设置为 60（即60秒）。
- 保存会话配置，避免每次手动设置。
第三步：配置SSH服务端主动探测（服务端视角）
如果无法控制客户端，或者希望从服务器端统一管理，可以修改服务器的 `sshd_config` 文件。此配置会让服务器主动询问客户端是否还在线。
编辑 /etc/ssh/sshd_config，确保以下参数未被注释，并进行如下调整：
ClientAliveInterval 60：服务器每60秒发送一次加密的空闲消息给客户端。ClientAliveCountMax 3：最多允许3次无响应，之后断开连接。
注意：修改后需重启SSH服务（`systemctl restart sshd`）生效。此方法的优势在于，即使客户端配置错误或不支持心跳，只要客户端进程存活，服务器也能感知到连接异常并及时清理僵尸会话，释放服务器资源。
第四步：排查MTU与分片问题（特殊情况）
在某些复杂的VPN或隧道场景下，SSH断连可能与路径MTU（PMTU）发现失败有关。如果数据包大小超过中间链路的MTU且DF（Don't Fragment）位被设置，数据包会被丢弃，导致连接看似中断但实际是丢包。
可以通过调整客户端的MSS或使用 `tcpdump` 抓包分析ICMP不可达消息来排查。一般情况较少见，但若上述心跳配置无效，可考虑强制客户端降低MSS值进行测试。
最佳实践与建议
- 双重保障：最佳实践是同时在客户端和服务端配置Keepalive。客户端配置保证了前端体验的连贯性，服务端配置确保了后台资源的及时回收和安全合规。
- 数值设定：心跳间隔建议在30-90秒之间。过短会增加不必要的网络开销，过长则可能无法有效防止防火墙超时。需根据企业网络的防火墙策略灵活调整。
- 监控告警：对于关键业务服务器，建议结合Zabbix或Prometheus等监控工具，监控SSH会话的存活状态。若检测到非预期的连接断开，可触发告警，排查是否存在网络安全攻击或网络链路故障。
- 文档记录：将修改后的配置文件纳入版本管理（如Git），并记录变更原因，以便后续审计和问题回溯。
总结
SSH频繁断连并非玄学，而是网络协议状态与中间设备策略协同工作时的常见副作用。通过理解TCP Keepalive机制，合理配置客户端和服务端的空闲探测策略，运维人员可以显著提升远程管理的稳定性和工作效率。在数字化转型背景下，这种细微但关键的优化，正是体现IT专业能力的重要细节。