通过 SSH 跳转另一台服务器，本质是在本地与目标机之间建立一条经过跳板机的加密隧道，最简洁的做法是用 ssh -J 参数一步直达。无论你是刚接触 Linux 服务器运维的新手，还是需要频繁登录生产环境的开发者，掌握这个操作都能让你少走很多弯路,下面直接进入正题。
ssh 跳转服务器的三种主流实现方式
在实际工作中，直接暴露目标服务器的公网端口存在较大安全风险，因此多数团队会采用堡垒机或跳板机方案，业内专家指出，合理使用跳板机是内网安全防护的基础手段之一，常见的 SSH 跳转方式有三种,你可以根据场景灵活选择。
ProxyJump 参数一次跳转（推荐）
OpenSSH 7.3 以上版本（大多数现代 Linux 发行版和 macOS 都已支持）内置了 -J 参数，举个例子，假设你有一台跳板机 IP 是 168.1.100，目标服务器内网 IP 是 0.0.5,登录命令就是：
ssh -J root@192.168.1.100 root@10.0.0.5
这条命令的含义是：先通过 SSH 连接跳板机，再由跳板机发起对目标机的连接，相比传统”先登录跳板机，再手动输入 ssh 命令”的方式，ProxyJump 的明显优势是只需一条命令、一次认证，且本地到目标机的数据传输全程加密,不会在跳板机留下明文交互痕迹。
ProxyCommand 配合 nc 命令
如果你的 SSH 版本较旧，或者跳板机有特殊的端口要求,也可以用标准输入输出转发的方式：
ssh -o ProxyCommand="ssh -W %h:%p root@192.168.1.100" root@10.0.0.5
-W 参数让跳板机把 TCP 连接直接转发给目标机的 SSH 端口（默认22），这种方式理论上兼容性更强，但命令较长，日常操作不如 -J 简洁。
SSH 配置文件起别名
对于需要频繁跳转的服务器，建议把连接参数写进用户级的配置文件 ~/.ssh/config,这样你只需要记住一个自定义别名就能登录：
Host jump
HostName 192.168.1.100
User root
Host target-serverHostName 10.0.0.5User rootProxyJump jump
保存后，直接执行 ssh target-server 就会自动通过跳板机连接目标机，这也是不少运维老手推荐的长期方案,便于统一管理多个服务器连接信息。
多级跳转与路径优化：ssh 跳转服务器命令的进阶玩法
有些内网环境存在多级隔离，比如办公网 → 前置跳板机 → 业务跳板机 → 数据库服务器，这时直接使用 -J 参数指定多个跳板即可：
ssh -J user@跳板机1,user@跳板机2 user@目标机
逗号分隔的顺序就是数据流经的顺序,这里有几个更贴合实际场景的细节：
- 若某级跳板机的 SSH 端口不是默认的22，需要写成
user@host:端口的格式。 - 建议给每一级跳板机都配置免密登录，否则多级跳转时每一跳都要输入密码,体验较差。
- 如果本地网络与跳板机之间的延迟较高，可以考虑加上
-o ConnectTimeout=10防止长时间卡住。
配置免密登录，让跳转和直连一样顺畅
频繁输入密码不仅影响效率，在脚本或自动化任务中更是无法实现，配置 SSH 密钥认证的步骤并不复杂：
- 在本地生成密钥对（若已有则跳过）：
ssh-keygen -t ed25519 -C "你的备注"，一路回车即可，默认生成在~/.ssh/目录。 - 使用
ssh-copy-id把公钥分发到目标机：ssh-copy-id root@192.168.1.100。 - 分别测试跳板机和目标机的免密登录是否生效。
如果目标机不允许直接通过密码认证，你还可以把本地的公钥手动追加到目标机对应用户的 ~/.ssh/authorized_keys 文件末尾，行业共识认为，密钥认证比密码认证更安全，且便于结合跳板机实现全程无感登录，关于免密登录更细致的配置方法，可以参考较早的 ssh-copy-id 使用文档。
常见问题排查与安全加固建议
即便配置正确，跳转时也可能遇到各种异常，以下三个问题出现的频率最高,提前了解能帮你快速定位。
跳板机连接正常，但目标机连接被拒绝
先确认目标机的 SSH 服务是否正常运行：systemctl status sshd（CentOS/RHEL 系）或 systemctl status ssh（Ubuntu/Debian 系），再检查目标机的防火墙是否放行了来自跳板机的 SSH 流量，如果安全组策略（如简米云、酷番云等云平台的安全组）有额外限制，也需要一并排查，需要特别说明的是，跳板机与目标机之间通常走内网 IP,要确保路由可达。
提示 “Permission denied (publickey)”
这说明目标机拒绝了当前认证方式，多数情况下是因为目标机的 /etc/ssh/sshd_config 中 PasswordAuthentication 被设为 no，而你的公钥又未正确配置,按上文免密登录章节操作即可解决。
跳转过程中断连，提示 “Timeout”
当内网策略严格时，长时间空闲的连接可能会被防火墙切断，你可以在 ~/.ssh/config 中为跳板机和目标机统一加上：
ServerAliveInterval 60
ServerAliveCountMax 3
这样客户端每隔60秒发送一次心跳包,让连接保持活跃。
跳板机 堡垒机 区别：选对方案再动手
很多刚开始接触服务器运维的朋友会混淆跳板机和堡垒机的概念，两者虽然都承担内网入口的角色，但定位和功能侧重有较大差异，跳板机本质是一台具备公网访问能力的普通服务器，只负责转发 SSH 流量，不关注细粒度的权限管控和审计，堡垒机则在跳板机的基础上引入了身份认证、操作审计、权限控制、指令拦截等企业级能力，更适用于合规要求高的生产环境,两者的核心对比如下：
| 维度 | 跳板机 | 堡垒机 |
|---|---|---|
| 部署成本 | 低，一台普通云主机即可 | 较高，需要专用软件或商业设备 |
| 权限控制 | 依赖系统用户和 SSH 权限 | 支持细粒度策略，如命令级审批 |
| 操作审计 | 基本没有或仅靠系统日志 | 完整录像、指令审计 |
| 适用场景 | 个人或小团队快速通道 | 等保合规、大中规模团队 |
如果你只是临时应急或个人实验，用 ProxyJump 加一台便宜跳板机即可满足需求；如果公司在做等保测评或需要满足审计要求，那直接采用堡垒机方案更稳妥，也不用后续再做二次改造，选择哪类方案，取决于你对安全审计的要求有多高,这也是运维场景里反复权衡的经典问题。
代理复用与效率提升
频繁创建 SSH 连接会带来额外的握手开销，利用 OpenSSH 的连接复用（ControlMaster）特性，可以让后续连接直接复用已有通道，明显提升跳转效率，在 ~/.ssh/config 中加入：
Host
ControlMaster auto
ControlPath ~/.ssh/controlmasters/%r@%h:%p
ControlPersist 10m
这样你在同一台服务器上连续操作时，后续连接几乎瞬间建立，需要留意的是，ControlPath 指定的目录需要先创建好,否则会报错。
另外有一个网络层面的讨论值得注意：在云服务器上，很多团队会通过修改 SSH 默认端口来降低被扫描概率，此时跳板机的端口也需要顺带调整，例如跳板机使用的是 2222 端口，那么目标主机连接配置中也要相应修改跳板机的端口号，否则 SSH 协议默认连接 22 端口会直接失败。
Q&A：ssh 跳转服务器命令的常见疑问
本机明明能直连目标机，为什么还要用跳板机？
直连存在两个隐患：一是目标机的 SSH 端口直接暴露在公网，容易遭受暴力破解；二是当目标机处于内网环境、没有公网 IP 时，本质上无法直连，通过跳板机，你只需要为这一台机器配备合理的防火墙策略，其余内网服务器全部隐藏在后面,攻击面大幅缩小。
使用 -J 参数跳转时，本地的公钥需要放在跳板机上吗？
不需要，跳板机在这里只负责转发 TCP 流，认证过程由本机与目标机直接完成，这意味着你在跳板机上不会泄露目标机的私钥配置,不过跳板机的系统用户仍然需要正确配置登录权限。
scp 或 rsync 是否也可以借助跳板机传输文件？
完全可以，把目标主机地址放在 -J 后面即可进行文件传输，例如将本地文件传送到目标机（经由跳板机）：
scp -J root@跳板机 /本机文件路径 root@目标机:/目标路径
同理，rsync 也支持通过 --rsh=ssh 等形式跳转，不过在 rsync 中正确的做法是使用 -e "ssh -J user@跳板机" 方式将跳板参数传给 SSH 通道，随着 OpenSSH 版本升级，-J 参数的组合用法已经相当成熟,可以说这类跳转写法已经成为大多数工程师操作内网服务器的首选方案。
最终回到开头那句话：SSH 跳转并没有想象中复杂，一条 -J 命令加上合理的密钥配置，就能让你安全、高效地触达任意内网服务器，构建连接时留出少量的额外时间用于检查防火墙、确认 SSH 版本，这些前期投入会在日复一日的操作里持续回报你，了解跳板机和堡垒机的差异，结合自己的场景选对方案,就不会在安全与效率之间反复纠结。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/773401.html
