serveraliveinterval 是 ssh 客户端参数，用于每 n 秒发送加密保活请求以维持连接活跃，须与 serveralivecountmax 配合使用，推荐 30 秒间隔配 3 次容错，兼顾防断连与安全性。

要维持 SSH 长连接的安全性与稳定性，关键不是“让连接永不中断”，而是**让连接在真实失效时能被及时发现并释放，在正常空闲时又不被中间设备误杀**。这靠的是两套协同机制：服务端主动探测（防链路静默断开）、客户端主动保活（补位或权限受限场景），再叠加 Shell 层防护（防会话被系统级超时终结）。三者缺一不可，但优先级分明。

服务端配置：统一管控，防中间设备清连接

这是最根本、覆盖最广的设置。所有连入该服务器的客户端都受惠，无需每台客户机单独操作。

• ClientAliveInterval 60：服务端每 60 秒向客户端发送一次加密心跳包（SSH_MSG_GLOBAL_REQUEST），确认链路存活。建议值 30–120 秒；设太小（如 10）+ ClientAliveCountMax=1 会导致“10秒必断”
• ClientAliveCountMax 3：连续 3 次未收到响应才关闭连接，即最多容忍约 3 分钟无响应。设为 0 表示禁用探测，务必避免
• TCPKeepAlive yes：启用内核级 TCP 保活作为兜底，辅助应对某些不识别 SSH 层心跳的老旧网络设备

修改 /etc/ssh/sshd_config 后执行 sudo systemctl reload sshd（轻量重载，不中断已有会话）。验证是否生效可运行：
sshd -T | grep -i clientalive

客户端配置：适配无服务端权限或特殊链路

当你只有普通用户权限，或连接路径中存在跳板机、ProxyCommand、企业代理等中间层时，服务端心跳可能无法穿透，此时需本地主动发包。

• ServerAliveInterval 60：客户端每 60 秒向服务端发一次保活请求（OpenSSH 5.4+ 支持）
• ServerAliveCountMax 3：连续 3 次无响应则断开本地连接，避免卡死状态

写入本地 ~/.ssh/config（Linux/macOS）或 C:\Users\用户名\.ssh\config（Windows）：

Host *<br>  ServerAliveInterval 60<br>  ServerAliveCountMax 3

图形终端如 MobaXterm、FinalShell、Xshell 均提供可视化 KeepAlive 开关，优先检查其界面设置是否已启用，避免配置冲突。

Shell 层防护：避免被 TMOUT 误杀

即使网络畅通、SSH 心跳正常，终端仍可能突然退出——这通常不是断连，而是 Linux Shell 自身的空闲限制在起作用。

• 运行 echo $TMOUT 查看是否启用；输出数字（如 600）表示 10 分钟无键盘输入即退出
• 临时禁用：unset TMOUT
• 永久禁用（仅限可信环境）：echo "TMOUT=0" >> ~/.bashrc && source ~/.bashrc
• 更稳妥方案：使用 tmux 或 screen 启动会话。它们独立于 SSH 连接生命周期，断线重连后可直接 tmux attach 恢复，对 tail、vim、长编译等场景极其实用

常见失效原因与排查要点

心跳参数看似正确却仍频繁断开，真凶往往藏在别处：

• 企业防火墙（如 Palo Alto、深信服）默认过滤 SSH_MSG_GLOBAL_REQUEST 类型报文，需在策略中放行
• iptables/nftables 的连接跟踪超时：nf_conntrack_tcp_timeout_established 若被设为 300 秒，TCP 连接空闲 5 分钟就会被内核强制清理
• 跳板机或 ProxyCommand 中间层未同步配置心跳，导致保活包在半路被截断
• 终端工具自带 KeepAlive 与 SSH 配置双重启用，反而引发行为冲突