SSH连接不超时需启用双向保活探测，必须同时配置ServerAliveInterval（如60）与ServerAliveCountMax（如5），单独设置无效；配置须写入~/.ssh/config并设权限600，服务端ClientAliveInterval为兜底且需重启sshd生效。
SSH连接不超时，不是调大“等待时间”，而是必须启用双向保活探测——只配客户端或只配服务端，90%的情况都会失效。
ServerAliveInterval 和 ServerAliveCountMax 必须一起配
单独写 ServerAliveInterval 60 没用。它只控制“多久发一次心跳”，但不决定“发几次没回就断”。SSH 客户端会直接忽略这个配置，除非同时指定 ServerAliveCountMax。
-
ServerAliveInterval 60：客户端每 60 秒向服务端发一个加密心跳包 -
ServerAliveCountMax 5：连续 5 次没收到响应才断开（即最多容忍 300 秒无交互） - 设成
ServerAliveCountMax 0是禁用机制，不是“永不超时” - 必须写入
~/.ssh/config，不能改/etc/ssh/ssh_config—— 后者影响所有用户，且易被系统更新覆盖 - 权限必须是
600：chmod 600 ~/.ssh/config，否则 SSH 直接跳过读取
ClientAliveInterval 在服务端怎么设才不踩坑
服务端的 ClientAliveInterval 是兜底手段，不是替代客户端配置。很多云服务器默认值为 0，等于完全关闭心跳。
- 编辑
/etc/ssh/sshd_config，确保这两行未被注释且值为正整数：ClientAliveInterval 60ClientAliveCountMax 5 - 别照搬网上“
ClientAliveInterval 10+ClientAliveCountMax 5”——这等于 50 秒就断，比默认还激进 - 改完必须重启服务：
sudo systemctl restart sshd；当前会话会断开，别在单连接里改完就关终端 - 先检查现状：
grep -E "^(ClientAlive|TCPKeepAlive)" /etc/ssh/sshd_config，有些镜像（如旧版腾讯云）默认设了ClientAliveInterval 10，得先覆盖
为什么加了保活还是断？三个常被忽略的干扰源
即使两端参数都对，掉线仍可能发生，问题往往出在“非 SSH 协议层”。
-
GSSAPIAuthentication yes默认开启，但多数内网服务器没配 Kerberos，导致输入密码后卡 10–30 秒——这不是掉线，是登录卡顿。解决：在/etc/ssh/sshd_config加GSSAPIAuthentication no，再重启sshd - 运行
echo $TMOUT，如果输出数字（比如600），说明 Shell 自己会在 10 分钟后退出，和 SSH 无关；临时解决：unset TMOUT - iTerm2、MobaXterm、SecureCRT 都有独立的 “SSH Keepalive” 开关，必须手动打开，且建议设成和
ServerAliveInterval一致
命令行临时覆盖最可靠，适合调试
当你不确定配置是否生效，或没有权限改 config 文件时，直接用 -o 参数最直观、优先级最高。
ssh -o ServerAliveInterval=60 -o ServerAliveCountMax=5 user@host- 该方式会绕过
~/.ssh/config和/etc/ssh/ssh_config中的同名设置 - 加
-vvv可验证：ssh -o ServerAliveInterval=60 -vvv user@host，等满 60 秒后看到debug3: send packet: type 80就说明心跳已发出
真正稳的组合不是“设多大值”，而是让探测节奏能穿透中间网络设备的 idle timeout——多数防火墙清空连接的阈值是 300 秒，所以 ServerAliveInterval 60 × ServerAliveCountMax 5 或 45 × 5 这类才是底线。别漏掉 TCPKeepAlive yes，它补的是底层 TCP 探测，但不能替代应用层心跳。
