适合读者：已经能使用 SSH，准备理解公司内网服务器为什么要“先经过一台入口”。本文区分通用 SSH 跳板与完整堡垒机产品，并用独立客户端配置解释 ProxyJump。域名和内网地址均为示意。
1. 为什么服务器不直接给每个人开放公网 SSH
有多台内网服务器时，可以把管理入口集中到专用主机或堡垒机平台。管理员先经过这个入口，再访问自己获准管理的目标。
这样容易集中控制来源、账户和访问流程，但“流量经过一台机器”并不自动等于已经具备审批、录像、命令审计和账号托管。先分清自己使用的到底是哪种系统，才能理解它提供了什么能力。
2. 直接 SSH、跳板机、堡垒机分别在解决什么
| 方式 | 典型访问路径 | 需要另外确认的能力 |
|---|---|---|
| 直接 SSH | 客户端 → 目标服务器 | 每台目标的入口、账户和日志管理 |
| 通用 SSH 跳板 | 客户端 → 跳板 → 目标 | 转发限制、目标授权、日志范围 |
| 堡垒机平台 | 客户端 → 受控访问平台 → 目标 | 实际启用的身份认证、授权、审计、录像及保留策略 |
堡垒机产品的接入方式可能是网页终端、专用客户端、SSH 网关或临时授权，不一定支持普通 ssh -J。下面的配置只适用于明确允许 OpenSSH TCP 转发的通用跳板环境；具体平台应使用它提供的连接方式。
3. ProxyJump 的连接过程是怎样的
设定三方：本地电脑、bastion.example.test 跳板、内网 10.20.0.15 目标。
客户端先对跳板建立 SSH 连接，再请求从跳板转发到目标的 TCP 端口。随后，本地客户端通过这条通道与目标建立自己的 SSH 会话。目标主机的身份和用户认证依然需要完成。
因此，两段连接可以使用不同账户、端口和密钥；目标服务器通常看到来自跳板的连接。ProxyJump 的定义见 OpenSSH ssh_config 手册。
这条方式不需要把个人私钥复制到跳板，也不要求启用 agent forwarding。它把连接通道接起来，并没有替你授予目标账户的登录权限。
4. 用独立文件写一份可检查的配置
先看客户端版本并准备配置目录。下面按 Linux/macOS 风格的客户端路径举例：
ssh -V
mkdir -p "$HOME/.ssh"
使用编辑器保存 ~/.ssh/config.ops-lab，不必改动现有主配置：
Host ops-gateway
HostName bastion.example.test
User gatewayops
Port 22
IdentityFile ~/.ssh/id_ed25519_gateway
IdentitiesOnly yes
ForwardAgent no
Host app-internal
HostName 10.20.0.15
User appops
Port 22
IdentityFile ~/.ssh/id_ed25519_app
IdentitiesOnly yes
ProxyJump ops-gateway
ForwardAgent no
ServerAliveInterval 30
ServerAliveCountMax 3
替换跳板地址、目标地址、账户和已获授权的密钥路径。示例不会生成或分发密钥，也不会修改任何服务器配置。
Host 是本地别名，HostName 是连接地址。通过别名登录时，客户端会选择对应的用户和身份文件；目标段的设置也不能简单假定为自动应用到跳板，所以两段分别写清楚。
Linux 客户端上，这种可能包含内部连接信息的配置文件可限制为本人读写：
chmod 600 "$HOME/.ssh/config.ops-lab"
5. 先展开配置，再进行真实登录
下面的 -G 用于查看配置，不会建立本次 SSH 会话；不过带有 Match exec 等额外规则的配置可能执行本地条件命令，本例没有这些规则。
ssh -F "$HOME/.ssh/config.ops-lab" -G app-internal | \
grep -E '^(hostname|user|port|proxyjump|identityfile|forwardagent) '
预期能看到目标地址 10.20.0.15、用户 appops 和 proxyjump ops-gateway。继续检查入口的配置：
ssh -F "$HOME/.ssh/config.ops-lab" -G ops-gateway | \
grep -E '^(hostname|user|port|identityfile|forwardagent) '
配置查询通过，只能证明客户端理解了这些选项。获得实际访问授权、网络条件和有效密钥后，再尝试：
ssh -F "$HOME/.ssh/config.ops-lab" -v app-internal
OpenSSH 参数的含义见 ssh 官方手册。首次连接时需要核对跳板与目标各自的主机身份，不能只确认入口就忽略目标。
登录后执行 whoami、hostname，确认最终进入的是目标账户与目标机器。连接成功但进入了跳板交互终端，和成功通过跳板进入目标不是同一结果。
6. 按两段链路排查，避免只盯一台机器
| 故障位置 | 常见证据 | 核对方向 |
|---|---|---|
| 客户端 → 跳板 | 域名错误、连接超时、入口认证失败 | 入口地址、VPN、来源规则、跳板账户与密钥 |
| 跳板 → 目标端口 | connect failed、拒绝连接、超时 |
目标监听、路由、安全组和主机防火墙 |
| 跳板转发策略 | administratively prohibited 等通道拒绝 |
允许的 TCP 转发及目标列表 |
| 目标 SSH 认证 | 目标阶段的 publickey 拒绝 | 目标用户、公钥来源和认证条件 |
通道拒绝提示需要结合跳板日志确认，不能仅凭文字就修改所有转发策略。跳板可能通过 AllowTcpForwarding、PermitOpen 或其他账户约束只允许指定目标；这些限制由管理员按访问范围配置。相关选项见 sshd_config 手册。
单独登录跳板能成功，不能证明跳板到目标的网络和策略也正常。排查记录要写清是哪一段、哪个地址和端口失败。
7. 经过跳板，就一定能记录目标里的所有命令吗
普通 ProxyJump 主要建立转发通道，目标 SSH 会话仍在本地客户端与目标之间加密。只是在入口运行普通 sshd，不能据此推断它能读到并录像所有目标终端内容。
如果业务要求会话录像或命令审计，需要确认平台如何终止、代理或采集会话，并在目标侧配合相应审计机制。还要验证记录是否覆盖实际客户端、文件传输和特定访问方式。
因此，验收堡垒机能力时，不只看“能不能登录”，还应在测试账户中执行一条可识别的教学命令，确认平台是否能按用户、目标和时间查到预期记录。具体做法按所用产品和授权范围执行。
8. 完成一次访问后，留下哪些信息
记录入口与目标的别名、网络路径、两段账户、认证方式、授权范围和有效时间；记录验证的主机身份、最终登录结果，以及实际可查到的审计内容。
遇到目标认证失败时，可以结合站内的 SSH 登录排查文章 继续定位。把“通道能否建立、目标能否认证、行为是否被审计”分别验证，才知道这条管理入口实际提供了哪些保障。