跳转至

一行 ProxyJump，VS Code 直达内网机器

内网机器藏在跳板机后面，是绝大多数公司的标准网络布局。手动操作的画风是：先登 host1，再从 host1 登 host2，最后从 host2 登 host3，改一行代码要在三个终端窗口之间来回横跳。

其实只要在 host1 的 ~/.ssh/config 里写一行 ProxyJump host2，VS Code 就能一键直达 host3——跳板机上什么都不用装，host3 的私钥也不用拷到 host2。

场景约定：host1 是你手头的机器，VS Code 跑在这里；host2 是跳板机，唯一作用是转发流量；host3 是藏在后面的内网目标机。下文所有配置，只改 host1 上的一个文件。

1. 背景：为什么需要跳板

典型网络分区长这样：办公网（host1）→ DMZ 跳板机（host2）→ 内网核心区（host3）。host3 对外不暴露任何端口，唯一入口是先登 host2。

手动穿透的痛，写几行就懂：

  • 每次都要两层 ssh 嵌套，输两遍密码或加载两把密钥
  • scp 传文件要先落到 host2 再转发一次，路径写起来像绕口令
  • 最难受的是 VS Code：Remote-SSH 的 Host 列表里根本没有 host3，远程开发直接没戏

解法不是给 VS Code 做什么特殊配置，而是把跳转逻辑下沉到 SSH 层——~/.ssh/config 写一次，命令行、VS Code、scp、git 全部受益。

2. 原理：ProxyJump 在做什么

ProxyJump 是 OpenSSH 7.3 引入的跳板指令，等价于老写法 ProxyCommand ssh -W %h:%p host2。

连接 host3 时，SSH 实际做了两件事：

  1. 先正常登录 host2，认证用的是 host1 对 host2 的凭据
  2. 让 host2 向 host3 的 22 端口发起一条 TCP 连接，之后只搬运字节

重点在第 2 步：host2 只转发 TCP 流量，不参与鉴权。host3 的 SSH 握手和认证，发生在 host1 的客户端与 host3 之间，端到端加密，host2 看到的全是密文。

所以 host2 上不需要存 host3 的私钥——密钥从头到尾没离开过 host1。这也是 ProxyJump 比"把私钥铺到每台跳板机"安全得多的根本原因。

Tip

如果你的场景是反过来的——机器没有公网 IP，需要从外部穿透进去拿 shell，那是反向隧道（ssh -R）的活，之前写过一篇完整踩坑记录。

3. 配置：ssh config 写法

在 host1 上编辑 ~/.ssh/config：

host1 的 ~/.ssh/config
# host1 连接 host2 的参数
Host host2
    HostName <host2 的 IP 或域名>
    User <host2 用户名>
    Port 22
    IdentityFile ~/.ssh/id_ed25519

# 通过 host2 跳板连接 host3
Host host3
    HostName <host3 的 IP 或域名>
    User <host3 用户名>
    Port 22
    ProxyJump host2
    IdentityFile ~/.ssh/id_ed25519
    ServerAliveInterval 30
    ServerAliveCountMax 3

关键就是 ProxyJump host2 这一行：SSH 在连接 host3 之前，先通过 host2 建立转发通道，然后在通道内直接连 host3。

几个细节：

  • ServerAliveInterval 30 + ServerAliveCountMax 3：每 30 秒发一次心跳，连续 3 次无响应才判定断线。远程开发动辄挂一整天，这组保活参数建议常备
  • host3 只能用内网 IP 访问、没有域名？HostName 直接写内网 IP——目标地址是交给 host2 去连的，host1 能不能解析根本不重要
  • host2 的端口、密钥有特殊配置？都写在 Host host2 块里，ProxyJump host2 会自动复用这些参数

验证只要一行命令：

ssh host3

能直接落到 host3 的 shell，配置就成了。有报错就 ssh -v host3 看握手过程，卡在哪一跳一目了然。

4. VS Code 一键连接

命令行跑通之后，VS Code 侧几乎零成本：

  1. 装 Remote - SSH 扩展
  2. 按 F1，输入 Remote-SSH: Connect to Host
  3. 列表里选 host3——~/.ssh/config 里的 Host 别名会自动出现
  4. 等待服务端自动安装（首次较慢，之后秒连）

连上后，资源管理器里就是 host3 的文件系统，终端也自动变成 host3 的 shell。编辑体验和本地基本一致，能感知到延迟的操作只有大范围的全文搜索。

Warning

命令行都连不上就别折腾 VS Code 了，先把 ssh host3 跑通。Permission denied 查密钥和用户名，Connection refused / 超时查 host2 到 host3 的地址和端口——ssh -v 的输出会告诉你卡在哪一跳。

5. 进阶：ProxyCommand 与链式跳板

OpenSSH 版本太老、或者你就是想显式控制转发，可以用等价的老写法：

Host host3
    HostName <host3 的 IP>
    User <host3 用户名>
    ProxyCommand ssh -W %h:%p host2

-W 表示把本地的 stdin/stdout 桥接到目标机的指定端口，效果和 ProxyJump 基本一样。但它是 2016 年之前的写法，新配置没有理由继续用——ProxyJump 更短、可读性更好，链式跳板写起来也更直观：

# 链式跳板：host1 → host2 → host2b → host3
ProxyJump host2,host2b

逗号分隔，四层网络照样穿透，每一段都复用各自 Host 块里的连接参数。

小结

一句话：先把 ssh host3 在命令行跑通，VS Code 只是复用同一份配置。

值得强调的是，这份配置的受益方远不止 VS Code——scp host3:~/log.txt .、rsync、git 的 ssh remote，所有走 SSH 的工具一夜之间全部直达。跳转逻辑下沉到 ~/.ssh/config 一次，上层应用零改动，这本身就是在正确的层解决问题的标准案例。

最后更新：2026-09-09

评论