必须同时配置客户端ServerAliveInterval（推荐60）与ServerAliveCountMax（推荐5），并写入~/.ssh/config按Host精确匹配、权限设为600；服务端需配合ClientAliveInterval（如300）与ClientAliveCountMax（如6）及TCPKeepAlive yes，重启sshd生效，且须规避云厂商NAT超时限制。
Linux SSH 加固中，会话保持与断开时间不是“设一个值就行”，而是客户端和服务端保活机制必须协同生效。只配一端、参数不匹配、权限或配置位置错误，都会导致设置失效。
客户端主动保活：用 ServerAliveInterval + ServerAliveCountMax
这是最常用且用户可控的手段，由本地 SSH 客户端发起心跳，防止 NAT 或中间设备（如光猫、云负载均衡）因空闲超时断连。
- ServerAliveInterval 推荐设为 60：每 60 秒发一次空包；设太小（如 10）易被家用路由器限速丢包，太大（如 120）可能赶不上 AWS/阿里云 ELB 默认的 60 秒空闲超时
- ServerAliveCountMax 推荐设为 5：连续 5 次没收到响应才断开，对应实际保活窗口为 5 × 60 = 300 秒（5 分钟），兼顾稳定性与及时性
- 必须写入 ~/.ssh/config，按 Host 精确匹配（不要盲目用 Host *），例如：
Host prod-db
HostName 10.1.2.3
User deploy
ServerAliveInterval 60
ServerAliveCountMax 5
文件权限必须是 600（chmod 600 ~/.ssh/config），否则 OpenSSH 直接忽略该配置。
服务端兜底探测：ClientAliveInterval + ClientAliveCountMax
服务端不“保持连接”，而是定期探测客户端是否存活。它不能替代客户端配置，但能补位——尤其当你有 root 权限且需统一管控所有接入连接时。
- ClientAliveInterval 设为 300（5 分钟），ClientAliveCountMax 设为 6 → 最大容忍 30 分钟无响应
- 别照搬网上“ClientAliveInterval 10 + ClientAliveCountMax 3”：这等于 30 秒就断，比默认还激进
- 务必同时开启 TCPKeepAlive yes，补 TCP 层级的链路探测能力
- 改完后必须重启服务：
sudo systemctl restart sshd；当前会话会立即断开，别在单连接里改完就关终端
避开常见干扰项
很多“掉线”其实不是超时，而是登录卡顿或中间链路拦截：
-
GSSAPIAuthentication yes 默认开启，但多数内网没配 Kerberos，会导致输完密码后卡 10–30 秒。解决方法：在
/etc/ssh/sshd_config中加一行GSSAPIAuthentication no，再重启 sshd - 检查是否被云厂商 NAT 超时覆盖：腾讯云/华为云部分镜像默认设了
ClientAliveInterval 10，需手动覆盖 - 心跳包要“发得出去、对方收得到、响应能回来”——三者缺一不可。防火墙、安全组、ACL 都可能拦截空包
临时调试与验证方法
不用改配置也能快速验证保活是否起作用：
- 命令行临时启用：
ssh -o ServerAliveInterval=60 -o ServerAliveCountMax=5 user@host - 连接后执行
echo $SSH_CONNECTION确认已连上，然后挂起终端 10 分钟观察是否断开 - 服务端查当前活跃连接：
ss -tnp | grep :22，看 ESTABLISHED 连接是否持续存在
