# SSH 无 Host 头的多租户路由：IP + 公钥元组方案 > SSH 协议缺乏 HTTP 的 Host header，导致多租户场景下无法像 HTTPS 那样基于域名路由。本文分析 IP+公钥元组、跳板机、端口复用等工程方案的取舍与落地参数。 ## 元数据 - 路径: /posts/2026/03/18/ssh-multi-tenant-routing-without-host-header/ - 发布时间: 2026-03-18T17:02:40+08:00 - 分类: [systems](/categories/systems/) - 站点: https://blog.hotdry.top ## 正文 SSH 协议的设计与 HTTP 有本质差异，这种差异在单租户场景下几乎透明，但一旦涉及多租户资源共享，就会暴露出令人头疼的路由难题。HTTP 依靠 Host 头实现同一 IP 上的域名分发，而 SSH 没有任何等价字段可供 L4 代理识别目标主机。本文将从协议缺陷出发，系统梳理当前工程界的主流应对策略，并给出可直接落地的参数建议。 ## 协议层面的根本限制 SSH 连接建立过程发生在 TCP 握手之后，客户端发送的第一个数据包是 SSH 协议版本字符串，其中不包含任何可解析的域名信息。此后的密钥交换阶段，客户端会提交公钥，但此时连接已经到达服务端，代理若不具备 SSH 协议解析能力就无法提前路由。换言之，SSH 缺乏一个在认证之前暴露目标主机身份的统一字段，这与 HTTP 的 Host 头或 TLS 的 SNI 完全不同。 这种设计取舍有其历史原因：SSH 诞生于点对点场景，默认假设每个 IP 对应一台明确的主机。但云计算时代改变了这一前提——同一个 IPv4 地址可能被数百个租户共享，每个租户名下又有多台虚拟机。如果不加改造地将 SSH 暴露给公网，服务端将无法判断连接应该路由到哪个租户的哪台机器。 ## 方案一：IP 元组路由 exe.dev 在其博客中详细阐述了一种实现方案：每个用户的虚拟机获得一个在其账户范围内唯一的 IP 地址。这个唯一性是相对于账户而言的——同一个 IP 段可能被多个账户的虚拟机使用，但单个账户内的每一台虚拟机都独占一个公网 IP。当 SSH 连接到来时，代理同时提取两个信息：来源 IP 地址和客户端提交的公钥。前者用于缩小账户范围，后者用于在账户内部定位具体的虚拟机。两者组合成 `{用户, IP}` 元组，即可唯一确定目标虚拟机。 这种方案的核心优势在于代理无需解析 SSH 协议内容，仅需在传输层捕获 IP 并在应用层读取公钥即可完成路由。部署时需要考虑以下参数：IPv4 地址池应预留足够的密度，建议按账户数乘以该账户平均 VM 数量再乘以 1.5 倍冗余进行规划；公钥提取发生在 SSH 认证阶段，代理必须具备终止 SSH 连接的能力，这意味着它实际上是一个 SSH 代理而非简单的 TCP 转发；云环境下需要处理公网 IP 到 VPC 内部 IP 的 NAT 映射问题，代理需要能够获取真实的入站源 IP 而非 NAT 后的地址。 ## 方案二：跳板机模式 对于无法改造 IP 分配策略的场景，跳板机是更通用的选择。每个租户或账户分配一个独立的跳转节点，该节点拥有固定的公网 IP，用户首先 SSH 登录跳转节点，再从跳转节点访问内部资源。这种模式将租户隔离从网络层转移到了认证层：跳转节点本身运行标准的 SSH 服务，内部资源可以完全隐藏在不暴露公网 IP 的私有网络中。 跳板机方案的工程复杂度在于用户的使用习惯改变。传统的 `ssh user@hostname` 单一命令变成了 `ssh -J bastion_host target_host` 两步操作，或者在 SSH 配置文件中预先配置 ProxyJump 指令。从运维角度看，跳板机需要独立的账户体系来管理租户权限，通常与 LDAP 或 OAuth 等身份提供商集成。跳板机本身的 SSH 服务配置应限制命令执行权限，仅允许端口转发和特定的内部主机访问，建议在 sshd_config 中配置 `AllowTcpForwarding yes` 并根据租户配置 `Match User` 块进行精细化授权。 ## 方案三：端口复用 如果租户数量可控且不愿意引入复杂的公钥路由逻辑，端口复用是最简单的替代方案。每个租户或每组虚拟机分配不同的 TCP 端口，代理仅根据目标端口进行 L4 转发。例如在同一个 IP 上，端口 2201 指向租户 A 的 VM1，端口 2202 指向租户 A 的 VM2，端口 3201 指向租户 B 的 VM1。这种方式的优点是实现极其简单，任何支持端口转发的反向代理或 iptables 规则都能胜任，调试成本极低。 但端口复用的可扩展性有限。IPv4 端口号范围为 1-65535，扣除系统保留端口后可用约 64000 个，如果每个租户平均需要 10 个端口，则理论上限约为 6400 个租户。更关键的是用户体验——用户需要记住 `ssh -p 2201 user@ip` 而非简单的 `ssh user@hostname`。对于需要提供简化访问界面的 SaaS 服务，这种方案往往需要配合自定义 SSH 配置或客户端工具来隐藏端口细节。 ## 方案对比与选型建议 | 维度 | IP 元组路由 | 跳板机模式 | 端口复用 | |------|-------------|------------|----------| | 实施复杂度 | 高 | 中 | 低 | | IP 资源消耗 | 中 | 低 | 中 | | 用户体验 | 最佳 | 中 | 差 | | 扩展性 | 好 | 最好 | 受限 | | 协议依赖 | 需 SSH 代理 | 标准 SSH | 标准 SSH | 对于需要提供「直接 SSH hostname」这样简洁体验的多租户平台，IP 元组路由是兼顾体验与资源效率的选择，但需要投入独立的 IP 管理与代理调度系统。如果团队运维能力有限或租户之间需要强隔离，跳板机模式虽然增加了一跳但能显著降低系统复杂度。当租户规模有限且以内部工具为主时，端口复用的最小实现成本仍具吸引力。 需要特别注意的是，无论选择哪种方案，都应在网络层配置入侵检测机制来监控异常 SSH 行为——尤其是来自同一来源 IP 的高频认证失败，这通常是暴力破解的前兆。配合 fail2ban 或云厂商的安全组规则，可以有效降低多租户环境下的横向渗透风险。 **资料来源**：本文技术细节参考 exe.dev 博客关于 SSH 无 Host 头的多租户解决方案。 ## 同分类近期文章 ### [好奇号火星车遍历可视化引擎：Web 端地形渲染与坐标映射实战](/posts/2026/04/09/curiosity-rover-traverse-visualization/) - 日期: 2026-04-09T02:50:12+08:00 - 分类: [systems](/categories/systems/) - 摘要: 基于好奇号2012年至今的原始Telemetry数据，解析交互式火星地形遍历可视化引擎的坐标转换、地形加载与交互控制技术实现。 ### [卡尔曼滤波器雷达状态估计：预测与更新的数学详解](/posts/2026/04/09/kalman-filter-radar-state-estimation/) - 日期: 2026-04-09T02:25:29+08:00 - 分类: [systems](/categories/systems/) - 摘要: 通过一维雷达跟踪飞机的实例，详细剖析卡尔曼滤波器的状态预测与测量更新数学过程，掌握传感器融合中的最优估计方法。 ### [数字存算一体架构加速NFA评估：1.27 fJ_B_transition 的硬件设计解析](/posts/2026/04/09/digital-cim-architecture-nfa-evaluation/) - 日期: 2026-04-09T02:02:48+08:00 - 分类: [systems](/categories/systems/) - 摘要: 深入解析GLVLSI 2025论文中的数字存算一体架构如何以1.27 fJ/B/transition的超低能耗加速非确定有限状态机评估，并给出工程落地的关键参数与监控要点。 ### [Darwin内核移植Wii硬件：PowerPC架构适配与驱动开发实战](/posts/2026/04/09/darwin-wii-kernel-porting/) - 日期: 2026-04-09T00:50:44+08:00 - 分类: [systems](/categories/systems/) - 摘要: 深入解析将macOS Darwin内核移植到Nintendo Wii的技术挑战，涵盖PowerPC 750CL适配、自定义引导加载器编写及IOKit驱动兼容性实现。 ### [Go-Bt 极简行为树库设计解析：节点组合、状态机与游戏 AI 工程实践](/posts/2026/04/09/go-bt-behavior-trees-minimalist-design/) - 日期: 2026-04-09T00:03:02+08:00 - 分类: [systems](/categories/systems/) - 摘要: 深入解析 go-bt 库的四大核心设计原则，探讨行为树与状态机在游戏 AI 中的工程化选择。