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 头的多租户解决方案。