ssh会话掉线主因是保活机制未配对，必须同时配置客户端serveraliveinterval（推荐45或60）与serveralivecountmax（推荐5），并写入~/.ssh/config按host精确匹配、权限设为600；服务端需配合clientaliveinterval（如300）与clientalivecountmax（如6）及tcpkeepalive yes，重启sshd生效，且须规避云厂商nat超时限制。
SSH会话掉线，不是网络差，而是保活机制没配对——只改一个参数、只配客户端或只配服务端，基本无效。
ServerAliveInterval 和 ServerAliveCountMax 必须一起设
这两个是 OpenSSH 客户端参数，ServerAliveInterval 控制每几秒发一次心跳包，ServerAliveCountMax 决定连续几次收不到响应就断开。单独设 ServerAliveInterval 会导致假死（卡住不动），设成 0 则完全禁用。
-
ServerAliveInterval推荐 45 或 60：太小（如 10）易被家用光猫限速；太大（如 120）赶不上 AWS ELB 的 60 秒空闲超时 -
ServerAliveCountMax推荐 5：意味着最多容忍 5 × 间隔 = 实际保活窗口（例如 60×5=300 秒） - 必须写进
~/.ssh/config，按Host精确匹配，比如：Host prod-server<br>HostName 10.20.30.40<br>User admin<br>ServerAliveInterval 60<br>ServerAliveCountMax 5
- 权限必须是
600：chmod 600 ~/.ssh/config，否则 SSH 直接忽略该文件
ClientAliveInterval 在服务端怎么配才不白改
服务端的 ClientAliveInterval 和 ClientAliveCountMax 是兜底手段，不是客户端配置的替代品。它只在你有 root 权限且能重启 sshd 时才起作用。
-
ClientAliveInterval设为 300（5 分钟），ClientAliveCountMax设为 6 → 最大容忍 30 分钟无响应 - 别照搬网上“
ClientAliveInterval 10+ClientAliveCountMax 5”：这等于 50 秒就断，比默认还激进 - 先检查现状：
grep -E "^(ClientAlive|TCPKeepAlive)" /etc/ssh/sshd_config，有些云厂商镜像（如腾讯云旧版）默认设了ClientAliveInterval 10，得先覆盖 - 改完必须重启：
sudo systemctl restart sshd；当前会话会断开，别在单连接里改完就关终端
配了还是断？优先排查这三处干扰源
心跳包能发出去、对方能收到、响应能回来，三者缺一不可。问题常出在非 SSH 协议层。
-
GSSAPIAuthentication yes默认开启，但多数内网服务器没配 Kerberos，导致输入密码后卡 10–30 秒——这不是掉线，是登录卡顿。解决：在/etc/ssh/sshd_config加GSSAPIAuthentication no，再重启sshd -
TMOUT是 Shell 自己的空闲退出变量，和 SSH 无关。运行echo $TMOUT，若输出数字（如 600），说明 Bash 10 分钟自动退出。临时禁用：unset TMOUT；永久关闭：在~/.bashrc加export TMOUT=0 - 终端复用工具干扰：
tmux默认idle-timeout是 10 分钟，screen也有类似设置，得手动关掉
TCPKeepAlive yes 有必要开吗
它可以补底层 TCP 层探测能力，防静默中断，但不是核心解法——它发的是未加密的底层 keepalive 包，很多云厂商 NAT 网关或企业防火墙会直接忽略。
- 建议开，但别依赖它：配合
ClientAliveInterval+ClientAliveCountMax使用，形成应用层+传输层双保险 - 服务端配置里加一行：
TCPKeepAlive yes，然后重启sshd - 注意：
TCPKeepAlive和ClientAlive*不冲突，前者是内核级，后者是 SSH 应用级，叠加更稳
真正容易被忽略的，是云厂商安全组/NAT 网关策略——比如阿里云 SLB 默认空闲超时 900 秒，AWS ELB 是 60 秒，你的 ServerAliveInterval 必须小于这个值的一半，否则心跳永远赶不上清理节奏。
