配置保活参数后多跳SSH隧道仍不定时断开如何排查解决

核心排查方向 #

• 逐跳校验配置生效状态：不要默认修改配置文件就一定生效，在每台涉及的服务器上执行以下命令校验参数加载情况：
  • 校验sshd服务端配置：sshd -T | grep -E 'clientaliveinterval|clientalivecountmax|tcpkeepalive'
  • 校验ssh客户端配置：ssh -G 127.0.0.1 | grep -E 'serveraliveinterval|serveralivecountmax'
    多数场景下配置不生效是因为发行版默认的ssh_config/sshd_config存在Include规则、Match块覆盖，或者修改配置后重启服务失败，参数根本没有加载。
• 中间网络设备会话超时排查：云服务商安全组、NAT网关、企业防火墙、运营商网关默认会定期清理空闲TCP会话，常见空闲超时阈值为60秒、300秒、900秒不等，且清理时不会向连接两端发送RST通知，两端会误以为连接仍存活，这也是连接断开时长无规律的核心原因——如果隧道持续有流量就会长期存活，一旦空闲时长触发阈值就会被直接掐断。
• 日志排查：在所有节点上查看断开时间点前后1分钟的sshd日志，执行命令journalctl -u sshd --since "对应断开时间前1分钟" --until "对应断开时间后1分钟"：
  • 如果日志中无任何连接关闭记录，连接直接消失，可判定为中间网络设备掐断连接
  • 如果日志中出现Broken pipe、Connection reset by peer，属于链路闪断
  • 如果日志中出现认证超时、会话数超限等明确报错，对应修复配置即可
• 资源异常排查：检查各节点/var/log/messages、/var/log/syslog中的OOM记录，确认sshd进程是否被系统因内存不足杀掉，同时检查sshd_config中MaxSessions、MaxStartups参数是否过低，导致连接被主动踢出。

可直接落地的修复方案 #

注意：你当前配置的ClientAliveCountMax 99999属于无效配置，只会导致sshd长期持有已经失效的僵尸连接、占用会话资源，建议调整为3即可，连续3次保活无响应即可判定连接失效，无需保留死连接。

• 逐跳显式加保活参数，跳过全局配置依赖
  不要依赖全局配置文件，直接在SSH命令中为每一段连接指定应用层保活规则，避免配置不生效问题，命令如下：

  ssh -D 9999 -N root@server_5 \
    -o "ServerAliveInterval=30" \
    -o "ServerAliveCountMax=3" \
    -o "TCPKeepAlive=no" \
    -o "ExitOnForwardFailure=yes" \
    -J "root@server_1 -o ServerAliveInterval=30 -o ServerAliveCountMax=3,root@server_2 -o ServerAliveInterval=30 -o ServerAliveCountMax=3,root@server_3 -o ServerAliveInterval=30 -o ServerAliveCountMax=3,root@server_4 -o ServerAliveInterval=30 -o ServerAliveCountMax=3"
  

  其中30秒的保活间隔短于绝大多数网络设备的最短空闲超时，能保证每一段连接不会被判定为空闲连接清理；关闭TCPKeepAlive是因为传输层保活包默认间隔过长，且容易被中间设备过滤，可靠性远低于SSH应用层保活包。
• 用autossh实现自动重连
  保活机制无法100%避免网络波动导致的断开，长期运行的隧道建议用autossh替代原生ssh，内置连接状态检测，断开后自动重连，安装autossh后启动命令如下：

  autossh -M 0 -N \
    -D 9999 \
    -o "ServerAliveInterval=30" \
    -o "ServerAliveCountMax=3" \
    -o "ExitOnForwardFailure=yes" \
    root@server_5 \
    -J "root@server_1,root@server_2,root@server_3,root@server_4"
  

  -M 0表示关闭autossh自带的端口监控，完全依赖SSH层的保活机制检测连接状态，-N表示不启动远程shell仅做转发，ExitOnForwardFailure=yes保证端口绑定失败时直接退出触发重连，避免出现端口不通的假活隧道。
• 长期运行建议加systemd托管
  如果隧道需要7*24小时运行，编写systemd服务文件托管autossh进程，配置开机自启、异常自动重启，稳定性远高于手动启动进程。
• 云环境额外配置：如果节点是云服务器，登录对应云平台控制台，将NAT网关、负载均衡、安全组的TCP空闲连接超时调整至300秒以上，配合30秒间隔的应用层保活即可避免连接被主动清理。

内容的提问来源于stack exchange，提问作者ana