实现本地与远程SSH端口转发隧道技术

SSH端口转发是一种常被遗忘的工具，直到防火墙、私有子网或复杂的供应商网络阻挡了简单路径时，它便成为最快捷的解决方案。你可以通过堡垒主机访问数据库、从笔记本测试私有管理页面，或将本地开发服务器暴露给无法直接访问你笔记本的机器。

基本思路很简单：SSH在连接的一端打开监听端口，并通过加密的SSH会话将流量传输到另一端的指定目标。容易让人困惑的是方向问题。使用-L的本地转发让你的机器能够访问SSH服务器附近的资源。使用-R的远程转发则让SSH服务器附近的机器能够访问你机器附近的资源。

本地转发：将远程服务带到你的笔记本

当你需要的服务可以从SSH服务器访问，但无法从你的工作站访问时，使用本地转发。

ssh -L 15432:db.internal.example:5432 [email protected]

连接后，你的笔记本会在127.0.0.1:15432上监听。当你将psql、DBeaver或应用程序配置指向该本地端口时，SSH会将流量发送到bastion.example.com，然后堡垒机建立到db.internal.example:5432的连接。

从左到右解读命令：

本地端口 : SSH服务器视角的目标主机 : 目标端口

“SSH服务器视角”这一细节很重要。如果数据库仅在私有网络内名为db.internal.example，你的笔记本无需解析该名称，堡垒机会处理。如果数据库仅在堡垒机的localhost上监听，则使用以下命令：

ssh -L 15432:127.0.0.1:5432 [email protected]

本地转发通常是更安全的默认选择，因为监听端口在你的工作站上。默认情况下，OpenSSH将本地转发端口绑定到回环接口，因此你Wi-Fi或办公网络上的其他机器无法使用该隧道。你可以明确指定：

ssh -L 127.0.0.1:15432:db.internal.example:5432 [email protected]

除非你确实想与其他主机共享隧道，否则避免绑定到0.0.0.0。像下面这样的命令会使你的笔记本成为私有数据库的代理，任何能访问你笔记本端口15432的人都可以使用：

ssh -L 0.0.0.0:15432:db.internal.example:5432 [email protected]

这在实验室中可能有用，但在普通工作站上很少需要。

远程转发：通过服务器暴露本地服务

远程转发翻转了监听端。当服务运行在你的机器上，但SSH服务器附近的某人或某物需要访问它时使用。

ssh -R 18080:127.0.0.1:3000 [email protected]

这要求public.example.com在端口18080上监听。对该端口的连接通过SSH传回你笔记本的127.0.0.1:3000。这在测试webhook接收器、共享临时演示或调试来自无法直接调用你笔记本的暂存系统的回调时非常方便。

一个常见的意外是：远程转发端口默认通常绑定到SSH服务器的回环接口。这意味着在public.example.com上运行curl http://127.0.0.1:18080可以工作，但从浏览器访问http://public.example.com:18080可能不行。

要使远程转发端口对其他机器可访问，SSH服务器必须允许。在/etc/ssh/sshd_config中，相关设置通常是：

GatewayPorts clientspecified

然后你可以请求公共绑定：

ssh -R 0.0.0.0:18080:127.0.0.1:3000 [email protected]

请谨慎使用。你正在通过服务器发布本地服务。在其前面放置防火墙，使用高随机端口，不要将管理工具、开发数据库或未经身份验证的应用暴露到互联网。

保持隧道稳定可靠

对于长时间运行的隧道，通常不需要远程主机上的shell：

ssh -N -L 15432:db.internal.example:5432 [email protected]

-N表示“不运行远程命令”。当隧道穿越会丢弃空闲TCP会话的NAT、VPN或云负载均衡器时，添加保活机制：

ssh -N \
  -o ServerAliveInterval=30 \
  -o ServerAliveCountMax=3 \
  -L 15432:db.internal.example:5432 \
  [email protected]

对于无人值守使用，优先选择systemd用户服务、autossh或进程管理器，而不是裸ssh -f命令。使用-f后台运行可行，但会使启动失败和隧道失效更难察觉。

ssh -fN -L 15432:db.internal.example:5432 [email protected]

如果使用-fN，先不带-f测试相同命令。密码提示、未知主机密钥提示和端口冲突在前台更容易诊断。

故障排查清单

当隧道连接成功但应用程序仍失败时，逐跳检查而非猜测。

首先，确认本地监听器存在：

ss -ltnp | grep 15432

然后从SSH服务器测试目标：

ssh [email protected] 'nc -vz db.internal.example 5432'

如果失败，则不是SSH转发的问题。堡垒机无法访问服务、名称无法解析、安全组阻止端口或服务绑定到错误接口。

如果监听器未启动，本地端口可能已被占用：

lsof -iTCP:15432 -sTCP:LISTEN

如果远程转发失败并显示类似remote port forwarding failed的消息，服务器可能阻止了TCP转发。检查sshd_config中的AllowTcpForwarding，并检查请求的端口是否已被占用。

值得保持的安全习惯

使用密钥认证并限制用于隧道的账户。对于专用隧道用户，可以结合受限的shell访问、防火墙规则以及SSH选项（如PermitOpen或PermitListen，取决于所需方向）。这些控制措施可防止便利的隧道变成广泛的网络访问。

在笔记或运行手册中按意图命名隧道，而不仅仅是命令。“笔记本15432到生产报告副本（通过堡垒机）”比shell历史中神秘的ssh -L行更易于审计。

本地转发帮助你向内访问。远程转发允许他人向你回连。一旦明确这一区别，大多数SSH隧道问题就变成了检查哪一端在监听、哪一端解析目标以及它们之间的防火墙。

你会看到的一些真实模式

一个常见的生产模式是数据库维护隧道。你有一个私有子网中的报告副本、一个具有严格SSH访问的堡垒机以及笔记本上的分析工具。本地转发非常适合：

ssh -N -L 127.0.0.1:15432:reporting-db.internal:5432 [email protected]

笔记本上的应用程序应使用127.0.0.1，而不是私有数据库主机名。如果工具坚持对数据库主机进行SSL主机名验证，你可能需要使用数据库主机名连接并添加本地hosts条目，或配置客户端使用正确的SSL模式。隧道仅传输TCP字节，不会重写数据库协议细节。

另一种模式是临时webhook接收器：

ssh -N -R 127.0.0.1:19090:127.0.0.1:9090 [email protected]

在此版本中，转发端口仅能从网关本身使用。然后你可以在网关上配置一个暂存服务来调用http://127.0.0.1:19090/hook。这比将端口发布到整个网络更安全。

对于短期公共演示，仅在添加防火墙规则后使用公共绑定：

ssh -N -R 0.0.0.0:19090:127.0.0.1:3000 [email protected]

然后限制网关：

sudo ufw allow from 203.0.113.40 to any port 19090 proto tcp

没有此限制，任何能访问网关的人都可以尝试转发服务。

SSH隧道无法解决的问题

SSH转发不能替代服务身份验证。如果数据库接受无密码的本地连接，隧道可能会将这种弱信任边界扩展到超出预期。如果本地开发应用没有登录页面，远程转发会将其原样发布。

它也不能使不稳定的目标变得可靠。如果堡垒机无法解析内部名称、服务宕机或安全组阻止路径，隧道仍可能成功建立而应用程序失败。这就是为什么从SSH服务器测试如此有用。

最后，隧道容易被遗忘。共享跳板机上的陈旧隧道可能留下意外开放的端口。对于任何长时间运行的任务，将命令放入具有清晰名称、所有者和重启策略的服务文件中。对于临时任务，完成后关闭它，并用ss -ltnp验证监听器已消失。