核心用法
ssh-tunnel-swarm 是一款纯 Bash 实现的 SSH 隧道集群管理工具，通过单一的纯文本规则文件即可批量启动并长期维持多条正向（-L）与反向（-R）SSH 隧道。用户只需定义连接块（每块包含目标主机、私钥路径及若干隧道规则），工具即会为每个主机启动独立的后台保活循环，自动处理断线重连（5 秒退避），直至收到 SIGINT/SIGTERM 信号后优雅退出。
运行方式极为简洁：无 CLI 参数，完全通过环境变量控制——RULES_FILE 指定规则文件路径，LOG_ENABLED/LOG_FILE/LOG_LEVEL 控制日志输出。执行后即进入前台阻塞状态，所有隧道子进程在其生命周期内受统一监管。
规则文件语法直观：每个连接块以 user@host:port=/path/to/key 开头，后续若干行用 forward 或 reverse 声明隧道，四元组 local-iface:local-port:remote-iface:remote-port 清晰映射端口转发逻辑。多块之间以空行分隔，天然支持多主机异构配置。
显著优点
1. 声明式批量管理：单文件即可描述跨多主机的复杂隧道拓扑，告别手工维护大量 ssh -L/-R 命令或 systemd 单元。
2. 自动弹性恢复：每个连接独立监控，断线后 5 秒自动重连，配合 ServerAliveInterval=30 与 ServerAliveCountMax=3 的保活探测，显著降低隧道静默中断风险。
3. 安全加固默认：强制启用 StrictHostKeyChecking=yes 与密钥认证（无密码支持），拒绝中间人攻击；私钥路径在启动时即校验存在性，权限失守时提前失败。
4. 零依赖轻量：仅需系统预装的 bash 与 ssh，无额外二进制、无守护进程、无配置 DSL 学习成本。
5. 优雅生命周期：信号驱动的统一清理机制，确保所有子进程在终止时有序释放端口与连接。
潜在缺点与局限性
- 功能边界明确：仅为 SSH 隧道封装，不提供 VPN/overlay 网络能力，亦不支持 NAT 穿透或多跳链路自动编排。
- 单向配置驱动：运行时无动态增删隧道的热更新能力，修改规则需重启进程。
- 日志与可观测性有限：虽有分级日志，但缺乏结构化指标输出（如 Prometheus 端点）、隧道流量统计及精细化事件追踪。
- 密钥管理负担：用户需自行确保障私钥文件权限（
chmod 600）及规则文件安全，工具本身无加密保管或密钥轮换机制。 - 网络权限敞口：
reverse隧道将本地服务暴露给远程主机，若远程遭入侵则形成攻击面；forward隧道同理将远程网络引入本地，需严格管控规则文件中的地址绑定范围。
适合的目标群体
- 后端/DevOps 工程师：需长期维护跳板机、数据库、内部管理后台等多资源访问通道。
- 全栈开发者：本地开发时通过反向隧道将服务临时暴露给远程测试环境或协作者。
- SRE 与运维团队：替代脆弱的 shell 脚本或手动 SSH 会话，以声明式配置实现隧道即代码（Tunnel as Code）。
- 安全敏感型组织：偏好密钥认证、主机密钥强校验、无额外依赖的极简工具链。
常规使用风险
- 配置失误风险：规则文件中错误的
user@host或端口将导致连接至非预期主机，或在生产环境误暴露服务；reverse规则若绑定0.0.0.0而非127.0.0.1，可能将本地服务公开至远程主机所在网络。 - 密钥泄露风险：私钥路径明文存储于规则文件，若文件被提交至 Git 或设为世界可读，将造成横向移动隐患。
- 资源占用风险：大量并发连接（尤其多主机场景）将占用本地文件描述符与内存，极端情况下可能触及系统限制。
- 日志敏感信息：若开启 DEBUG 日志，可能记录连接元数据，需确保日志文件权限与存储位置合规。
- 进程管理风险：前台运行模式要求用户自行搭配 systemd/screen/tmux 等实现后台托管与开机自启，否则终端退出即导致隧道中断。