EC2机器中Python SSHTunnelForwarder高连接量时后台关闭隧道问题排查

1. SSH客户端侧连接限制检查 #

• 编排器作为SSH客户端，自身也存在连接数限制，检查/etc/ssh/ssh_config或用户目录下的~/.ssh/config，确认是否有MaxSessions相关配置（客户端侧默认可能存在上限）
• 查看系统级文件描述符限制：
  • 执行ulimit -n查看当前进程的文件描述符上限，SSH隧道每个连接会占用多个文件描述符，40台机器的规模可能超过默认限制
  • 临时调整可执行ulimit -n 1024，长期调整需修改/etc/security/limits.conf，添加：

    * soft nofile 1024
    * hard nofile 4096
    

2. SSHTunnelForwarder自身配置优化 #

• 启用心跳保活机制，避免SSH连接因闲置被中间网络设备（如NAT网关、防火墙）断开，在SSHTunnelForwarder配置中添加：

  ssh_config={
      "ServerAliveInterval": 30,
      "ServerAliveCountMax": 3
  }
  

• 确认隧道的keepalive参数是否正确设置，部分版本的SSHTunnelForwarder需要显式开启保活功能
• 检查代码中是否设置了过短的超时时间，批量创建隧道时可能触发超时断开

3. EC2网络层限制排查 #

• 检查编排器EC2的TCP连接数上限：AWS EC2实例有默认的TCP连接数限制，M5系列中小规格实例的默认连接数可能不足以支撑40条SSH隧道+gRPC连接，可通过AWS控制台查看实例网络性能指标，确认是否达到TCP连接数阈值
• 核查VPC的网络ACL和安全组规则，确认是否存在针对SSH（22端口）或gRPC端口的连接数限制，部分安全组规则可能隐含连接数阈值
• 排查中间NAT网关的连接数限制，若编排器通过NAT网关访问其他EC2，NAT网关有并发连接数上限（默认100000，但批量短连接场景可能快速耗尽）

4. 目标EC2的SSH服务端其他限制 #

• 检查目标EC2的/etc/ssh/sshd_config中的ClientAliveInterval和ClientAliveCountMax参数，若服务端未配置保活，闲置连接会被主动断开
• 查看目标EC2的/etc/security/limits.conf，确认服务端的文件描述符上限是否足够，每个SSH连接会占用服务端的文件描述符资源
• 查看目标EC2的系统日志（/var/log/auth.log或/var/log/secure），查找SSH连接被断开的具体错误信息，比如error: maximum authentication attempts exceeded或connection closed by remote host

5. 代码层面问题核查 #

• 检查SSHTunnelForwarder的启动方式，是否使用异步或多线程/多进程模式，单线程批量创建隧道可能导致连接超时或资源竞争
• 确认是否正确处理了隧道的异常断开逻辑，是否具备重连机制，部分隧道断开后未被及时检测到，会导致is_active状态变为False
• 排查gRPC服务的连接池配置，虽然CPU、内存未达上限，但gRPC的keepalive_time设置过短可能导致频繁重连，间接影响SSH隧道稳定性

6. 系统日志深度排查 #

• 查看编排器的系统日志（/var/log/auth.log或/var/log/secure），查找Received disconnect from ...类日志，根据错误码定位断开原因
• 查看编排器的dmesg日志，检查是否存在TCP: too many orphaned sockets等网络相关错误
• 开启SSHTunnelForwarder的DEBUG日志（设置logger=logging.getLogger("sshtunnel")并配置日志级别为DEBUG），获取隧道创建和断开的详细过程

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