一台 Mac 屏幕：本地 SSH 转发还是完整 VPN？

你需要从自己的机器上看到一台 Mac 的屏幕，这台 Mac 位于一个你已经能通过 SSH 登录的主机之后，问题在于这是否值得上 VPN。通常不值得。一条本地转发就通过已有的 SSH 会话携带一个 TCP 端口，对单个主机上的一块屏幕来说，这比路由整个网络更小、也更容易审计。

三个条件决定它，其中任何一个都可能把你推向受管 VPN。

三个条件决定它

第一是范围：单个主机上的一个服务，还是多个主机和多个端口。第二是堡垒机与目标之间的每一跳是否已经可信，因为 SSH 只保护它终接的那一段。第三是搭好之后由谁来维护这套安排，因为手工搭的隧道往往比懂它的人活得更久。开始之前就点名那个人，并把命令写在他找得到的地方。没有文档的转发，是一场开始日期被推迟的未来事故。

如果答案是“一个”“是”“目前是我”，转发就是合适的工具。只要有任何一个答案改变，一年下来，有支持的远程访问设计就比事后处理无文档隧道的事故复盘更便宜。

转发一个端口，而不是整个网络

本地转发在你的机器上打开一个监听端口，把每个连接经 SSH 服务器中继到它能到达的目标。对于屏幕共享服务监听 TCP 5900 的 Mac，以及能解析 mac.corp.example 的堡垒机，这条命令很短，而且刻意做窄。其中每个选项都是为了把这套安排保持得小：不要 shell、不要监听所有接口、不要守护进程。把它当作对范围的声明，而不是菜谱。

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:15900:mac.corp.example:5900 [email protected]

把监听器绑定到 127.0.0.1，就让它避开了其他所有接口。这不是形式问题：绑定在所有接口上的转发会让你在同一家咖啡馆 Wi-Fi 里的任何人，都能把你的笔记本当成进入公司网络的开放中继。如果端口已被占用，换一个高位端口并更新查看器；不要为了让示例成立而停掉无关服务。

堡垒机上的账号也需要被允许向那个目标转发。有些加固的 SSH 配置完全禁用端口转发，有些则用 permit-listen 或 permit-open 指令加以限制。在把被拒绝的通道理解为密码错误之前，先读服务器策略。

SSH 加密了什么，又在哪里停止

SSH 会话保护从你的 Mac 到堡垒机的流量，而转发在并不理解 VNC 协议的情况下，把它装在这段会话里。连接一旦离开堡垒机走向目标，就不在你的 SSH 会话里了。最后一跳上无论有什么保护，都属于目标协议和私有网络自身的控制。

因此，不能因为第一跳用了 SSH，就把普通 VNC 的最后一跳描述成端到端加密。诚实描述各段：从客户端到堡垒机是强的，之后取决于目标支持什么。如果要求整条路径由同一种机制加密，转发就满足不了。

目标端的认证又是另一回事。SSH 账号并不授予 macOS 登录，屏幕共享服务仍然要求它自己的凭据，也仍然应用它自己的访问列表。一个接受连接的本地监听器，并不能证明远端服务是否会放行这个会话。

何时该选完整 VPN

当任务需要一个以上端口时，选 VPN：Apple Remote Desktop 的管理和报告功能会用到单条 TCP 转发无法承载的额外 TCP 和 UDP 流量。转发不是整个产品的部分实现；它是另一种、更小的工具。

当多个管理员从变化的地点接入时选它，因为受管配置文件会分发路由、凭据和策略，而不必每个人自己发明命令行。当审计轨迹需要显示谁连了什么时选它，因为按用户划分的 SSH 会话与共享的本地转发留下的记录差别很大。

最后，当目标网络本就不该在没有组织自己的门禁时从笔记本触达，选 VPN。个人转发在设计上就绕过那道门，正因如此它该进变更记录，而不是 shell 历史。

让转发大声失败

使用 ExitOnForwardFailure=yes，让绑定失败时停止会话，而不是留下一个看起来连着、却什么都没转发的 shell。保持主机密钥校验开启，优先用密钥或代理，而不是密码。然后测试查看器将使用的确切 URL，因为能用的 SSH 会话和能用的屏幕连接是两个不同的结果。

在 macOS 上，原生客户端通过本地 URL 访问查看器：open "vnc://127.0.0.1:15900"。如果窗口打开、远端主机拒绝认证，隧道是好的，问题在目标端。如果窗口从不打开，问题在监听器或端口。

用完后停止会话，并写下端口、堡垒机、目标和账号策略。没人记录过的转发，半年后与后门无从区分；这就是要让它小、有名字、临时的最强理由。