在 HTTP/HTTPS 反向代理场景中，基于域名的路由是基础设施的标配能力。Nginx 可以根据请求头中的 Host 字段将流量分发到不同的后端服务，Traefik 可以基于域名规则动态发现服务，AWS ALB 则支持基于主机条件的路由规则。这套机制之所以可行，核心前提是客户端在请求中明确携带了目标域名信息 ——HTTP 的 Host 头或者 TLS 握手阶段的 SNI（Server Name Indication）扩展。然而，当我们将目光投向 SSH 协议时，这套看似天经地义的路由逻辑 suddenly 失效了。

SSH 协议在设计时采用了与 HTTP 完全不同的抽象层次。HTTP 是应用层协议，它在请求行之后紧跟 Host 头，负载均衡器可以在解密前（即 TLS 终止前）读取该字段完成路由决策。SSH 则不同，它本质上是运行在 TCP 之上的二进制协议，客户端直接连接到 IP 加端口的组合，随后进行的 SSH 握手过程中并不包含任何与目标主机名相关的字段。这意味着反向代理无法像处理 HTTPS 请求那样，在 TCP 连接建立后、SSH 协议解密前获取 “乘客身份信息” 来完成智能路由。

更关键的是，SSH 没有类似 TLS SNI 的扩展机制。SNI 之所以能让 HTTPS 在单个 IP 上托管多个域名，是因为客户端在 ClientHello 阶段就以明文形式发送了目标服务器名称，使得负载均衡器可以在 TLS 加密建立之前完成证书选择和路由分发。SSH 的握手过程从加密密钥协商开始，所有的协议内容在传输层就已经被加密处理，反向代理没有任何 hook 点可以在不破坏安全性的前提下提取目标主机信息。

面对这一协议层限制，多租户 SSH 服务场景下存在三种主流工程实践，每种方案在运维复杂度、安全边界和扩展性上各有取舍。

第一种方案是 IP 或端口分片。每个租户分配独立的公网 IP 地址，或者在同一 IP 上使用不同端口（如 2201、2202、2203）映射到不同后端。这种方式的优势在于实现简单，现有的 SSH 客户端无需任何修改即可使用，配合 DNS 的 CNAME 记录可以将域名解析到特定 IP 或端口。例如，tenant-a.example.com 解析到主机的 2201 端口，tenant-b.example.com 解析到 2202 端口。运维层面需要关注端口耗尽速度 —— 单个主机可分配的临时端口范围通常在 32768 到 60999 之间，但如果使用固定端口方案，建议为每个租户预留至少一个专属端口，并设置端口使用率监控阈值（建议超过 70% 时触发告警）。这种方案的缺点是 IP 地址资源成本较高，且在 IPv4 地址日益稀缺的场景下难以大规模扩展。

第二种方案是跳板机架构，也称为 Bastion Host 模式。所有租户的 SSH 流量先汇聚到一个统一的入口点，经过身份认证后再由跳板机根据用户身份或所属租户将其转发到对应的后端服务器。这与 HTTP 反向代理的逻辑本质相似，只是路由决策发生在应用层而非传输层。跳板机可以基于用户名、SSH 密钥指纹或者客户端证书的 Subject Alternative Name 字段来识别租户身份。工程落地时需要关注跳板机的并发连接数上限（建议根据 SSH 进程占用内存估算，单节点控制在 5000 并发以内为佳），以及内网转发的网络延迟（跨可用区跳板机的 SSH 操作延迟可能增加 20 至 50 毫秒）。SSH 的 ProxyJump 特性（ssh -J bastion.example.com target.internal）就是这一架构的原生实现，OpenSSH 7.3 以上版本均支持。

第三种方案是基于 SSH 证书的逻辑隔离。租户不再通过端口或 IP 区分，而是通过 SSH 证书认证体系进行身份绑定。所有租户使用同一台 SSH 服务器，但每张用户证书在生成时嵌入了特定的角色或租户标识，服务器的 AuthorizedPrincipalsFile 配置可以根据证书主体将用户映射到不同的授权集合。这种方式可以实现真正的单入口、单端口多租户架构，运维复杂度集中在证书颁发和吊销管理上。建议使用独立的 SSH Certificate Authority 服务器，证书默认有效期设置为 24 至 72 小时，吊销列表检查间隔不低于每小时一次。对于密钥管理，建议采用 HashiCorp Vault 或 CloudKMS 等密钥管理系统存储 CA 私钥，避免单点故障导致的整个租户体系崩溃。

需要特别指出的是，市面上存在一种将 SSH 封装在 TLS 内部的曲线救国方案 —— 即在 SSH 服务器前部署支持 SNI 的 TLS 反向代理，客户端通过 HTTPS 端口的 WebSocket 或 stunnel 建立 SSH 隧道。这种方式虽然可以利用 SNI 实现基于域名的路由，但需要租户侧安装专用客户端或配置复杂的隧道参数，实际落地时需要评估终端用户的接受度和技术支持成本。

综合来看，如果多租户规模在数十个以内且对运维自动化要求较高，跳板机架构是成熟且低风险的选项；如果追求极致的资源利用效率且租户数量可能快速增长，SSH 证书逻辑隔离方案提供了更优雅的扩展路径；而 IP 或端口分片则适用于存量系统改造或租户数量较少、对安全性要求严格的合规场景。无论选择哪种路径，核心要点在于认识到 SSH 协议层的这一先天限制，并将多租户路由的决策点从传输层上移至应用层或身份认证层。

资料来源：Hacker News 讨论帖（https://news.ycombinator.com/item?id=46724730）以及 exe.dev 博客对 SSH Host 头的分析（https://blog.exe.dev/ssh-host-header）。