引言
在企业IT运维管理中，远程管理服务器的稳定性是保障业务连续性的基础。许多系统管理员曾遇到这样一个棘手的问题：当用户通过SSH客户端连接Linux服务器执行长时间任务（如大数据处理、大规模编译或备份）时，连接会突然中断，且没有任何明显的错误提示，或者仅显示“Connection closed by remote host”。这种非预期的断连不仅影响工作效率，更可能在关键时刻导致业务数据不一致。
本文将深入探讨两个常被忽视但至关重要的因素：Keepalived的健康检查机制与PAM/TCP Keepalive配置，并提供具体的排查与解决步骤。
一、 Keepalived健康检查导致的“假性”断连
在许多高可用架构中，Keepalived常用于实现VIP（虚拟IP）的漂移和高可用监控。然而，Keepalived默认的健康检查脚本往往只关注系统是否响应简单的ping包或服务端口（如HTTP 80）是否开放，而忽略了现有的活跃TCP连接状态。
1.1 故障现象分析
当Keepalived检测到主节点服务异常（例如，某个内部监控指标轻微超标，或脚本执行超时），它会触发VIP漂移至备用节点。此时，所有建立在原主节点上的TCP连接（包括SSH会话）会被立即重置（RST包）。SSH客户端通常不会收到标准的关闭报文，而是直接抛出“Connection reset by peer”或静默断开。
1.2 排查与验证方法
步骤1：查看系统日志
登录备用节点或通过集群日志中心，检查在断连时间点是否有Keepalived切换事件：
grep VRRP /var/log/messagesgrep keepalived /var/log/syslog
步骤2：检查健康检查脚本逻辑
审查Keepalived配置中的vrrp_script部分。很多运维人员编写的检测脚本过于敏感，例如仅仅因为磁盘IO略高就判定节点故障。建议将检测粒度调整为与服务业务强相关的指标，而非系统底层资源。
1.3 解决方案
为了减少因短暂波动导致的误切换，可以调整Keepalived的权重和检测间隔：
建议在vrrp_instance中增加
track_script的延迟判断逻辑，或使用更稳健的检测方式，避免瞬时抖动引发VIP频繁漂移。
二、 TCP Keepalive与SSH会话保活配置
如果排除了Keepalived的因素，大多数SSH意外断开的原因在于中间网络设备（防火墙、负载均衡器）或操作系统内核的TCP Keepalive机制超时。网络设备通常会在空闲连接超过一定时间（如30分钟）后强制切断连接，以释放资源。
2.1 理解TCP Keepalive与ClientAlive
TCP层面的Keepalive由内核控制，而SSH层面的保活由sshd_config控制。两者协同工作：
- ClientAliveInterval/ClientAliveCountMax：这是解决此问题最直接的方法。它们告诉sshd定期发送保活消息给客户端。
- SO_KEEPALIVE：Linux内核的TCP Keepalive，默认间隔较长（通常2小时），对于快速切断空闲连接的防火墙来说，这个间隔太长了。
2.2 服务端配置优化
修改/etc/ssh/sshd_config文件，启用并调整客户端保活策略：
# 每120秒发送一次保活请求
ClientAliveInterval 120
允许最大无响应次数为3次，即360秒后断开（若客户端无响应）
ClientAliveCountMax 3
修改完成后，务必重启sshd服务：systemctl restart sshd。
2.3 客户端配置优化
为了配合服务端，客户端也应开启Keepalive。在~/.ssh/config中添加：
Host *
ServerAliveInterval 60
ServerAliveCountMax 3
这将确保SSH客户端每隔60秒向服务器发送一个空数据包，使中间防火墙认为连接是活跃的。
三、 PAM模块与会话超时的深层关联
在某些企业环境中，PAM（Pluggable Authentication Modules）配置可能会影响会话的生命周期。特别是当使用了pam_limits.so或pam_tally2.so等模块时，可能会因为资源限制或安全策略导致会话被强制终止。
3.1 检查PAM配置
查看/etc/pam.d/sshd文件，确认是否有过于严格的会话超时设置。虽然PAM主要控制认证和账户管理，但某些定制化的PAM模块可能集成会话清理功能。
3.2 审计日志分析
结合auditd日志，查看在断连时刻是否有进程被kill或资源被回收的操作：
ausearch -m SYSCALL -ts recent | grep sshd
四、 综合排查流程图
当遇到SSH频繁断开问题时，建议遵循以下逻辑进行排查：
- 确认断连类型：是瞬间重置（RST）还是超时断开？使用tcpdump抓取数据包分析。
- 检查高可用层：查看Keepalived日志，排除VIP漂移导致的连接中断。
- 检查网络设备：联系网络团队，确认中间是否存在短时空闲连接切断策略。
- 调整SSH参数：实施上述ServerAliveInterval和ClientAliveInterval配置。
- 监控底层资源：使用top或htop观察断开瞬间的系统负载，排除OOM（内存溢出）杀手进程的影响。
结语
SSH连接的稳定性看似是一个简单的网络问题，实则涉及高可用架构设计、操作系统内核参数以及中间件配置的多个层面。通过深入理解Keepalived的工作机制，并合理配置TCP Keepalive与SSH保活参数，IT运维人员可以有效解决绝大多数非预期的会话断连问题，为企业的稳定运行提供坚实的技术保障。
