Nginx stream模块仅支持TCP层端口转发，无法解析SSH握手内容，故不能基于用户或目标主机实现智能分发；它可做简单负载均衡，但不提供认证透传、会话保持或协议级路由能力。
不能直接用 Nginx 对 SSH 做四层负载均衡分发，因为 Nginx 的 stream 模块虽支持 TCP 代理（即四层转发），但 不支持 SSH 协议识别、会话保持、用户级路由或认证透传。所谓“SSH 跳板分发”若指将不同用户/主机请求智能调度到后端 SSH 服务器，Nginx 本身不具备解析 SSH 握手内容（如用户名、目标主机名）的能力，无法实现基于业务逻辑的分发。
为什么 Nginx stream 不能真正“分发 SSH 请求”
Nginx stream 模块仅工作在传输层，可做纯 TCP 端口转发，例如：
- 把
2222端口的连接，按轮询或 IP hash 转发到多台 SSH 服务器的22端口； - 但所有连接对后端 SSH 服务来说，源 IP 可能被掩盖（除非开启 proxy protocol 并后端支持）；
- 它无法知道客户端想登录的是哪个用户、哪台目标机器（比如跳板后还要连内网 A/B 主机），更不能根据
ssh user@host -p2222中的host做路由； - SSH 认证过程（密钥交换、协议协商）完全由后端 OpenSSH 处理，Nginx 不参与也不感知。
真正可用的 SSH 跳板加固与分发方案
若目标是统一入口、权限隔离、操作审计和后端分流，应组合使用专业组件：
- 用 Teleport 或 Apache Guacamole 做带身份识别的 SSH 网关：它们能解析 SSH 连接中的用户名、目标地址，支持 RBAC、会话录制、双因素认证；
- 用堡垒机（Jump Server）如 JumpServer（开源）或商业产品：提供 Web SSH、命令审计、资产纳管、动态授权，天然支持“一个入口，分发到多个目标主机”；
-
若坚持用 Nginx stream，仅限简单 TCP 负载场景：例如把高并发的 SSH 连接压力分散到多台配置相同的跳板机，此时需确保：
- 后端所有跳板机使用相同密钥体系或集中认证（如 LDAP/SSO）；
- 启用
proxy_protocol并在 OpenSSH 配置中启用UseProxyProtocol yes（OpenSSH 9.0+ 支持）以保留真实客户端 IP； - 关闭 Nginx 的连接复用（SSH 是长连接，不适用 HTTP keepalive 逻辑）。
一个最小可行的 Nginx stream 四层转发示例（仅负载，无业务分发）
/etc/nginx/nginx.conf 中添加：
stream {
upstream ssh_backend {
hash $remote_addr consistent;
server 192.168.1.10:22 max_fails=3 fail_timeout=30s;
server 192.168.1.11:22 max_fails=3 fail_timeout=30s;
}
<pre class="brush:php;toolbar:false;">server {
listen 2222;
proxy_pass ssh_backend;
proxy_timeout 1h;
proxy_responses 1;
proxy_protocol on; # 若后端 OpenSSH 支持 Proxy Protocol
}}
注意：该配置只是把连接随机/哈希分发，不是按用户或目标主机分发，也不提供任何 SSH 层面的安全增强（如防暴力破解、命令拦截、审计日志），这些必须由后端跳板机自身完成。
想实现“基于用户或目标的智能跳转”，必须用理解 SSH 协议的应用层网关，Nginx 不是合适工具。把它当 TCP 负载器用可以，但别指望它替代堡垒机或 SSH 网关的核心能力。
