单台设备的反向 SSH：环回监听还是路由式 VPN？

为只能向外拨号的设备提供一个管理端口。三个条件决定反向隧道是否够用，还是需要真正的路由路径。

你的设备位于运营商 NAT 之后，能够发起出站连接，并运行着无人能够访问的 SSH 服务器。收到的请求通常被表述为“给它一个 VPN”，而这只是若干答案之一。在接受之前，请先判断你需要的是一个管理用 TCP 端口，还是 通往整个子网的路由路径，因为那是暴露面不同的不同项目。

反向隧道能很好地回答较窄的那种需求。设备向你的中心拨号，请中心在环回端口上监听，再把该端口转发回它自己的 SSH 服务。之后管理员通过中心而不是公网访问监听端。

三个条件决定选择

在做任何配置之前先写下这些条件。它们是受限管理入口与网络扩展之间的分界线，混为一谈就会让五行隧道变成无人负责的平坦网络。

ConditionReverse tunnel fitsSomething else is needed
How many services must be reachable?One, or a small fixed set on loopbackAnything that needs many ports or dynamic discovery
Who connects, and how are they authenticated?Named administrators with their own hub accountsThird parties, or anything needing per-flow audit you do not control
Does the device's own LAN need to be reachable?NoYes, so a routed VPN or a managed platform is the honest answer

第三行正是人们争论的那一条。通往设备 SSH 端口的隧道并不会把它的邻居放进你的网络，也不应通过更多转发的链条让它看起来如此。如果需求真的是 LAN，就说清楚，并改为设计 LAN。

中心侧：受限的中继账户

为每台设备分配各自的公钥认证、且不带交互式会话的中继账户。 Match 把块限定在该账户上可以让授权保持很小，私钥则留在它该在的设备上。

Match User relay-dev-7
    AuthenticationMethods publickey
    PubkeyAuthentication yes
    AllowTcpForwarding remote
    PermitListen 127.0.0.1:21022
    GatewayPorts no
    MaxSessions 0
    PermitTTY no
    X11Forwarding no
    AllowAgentForwarding no

MaxSessions 0 是有意思的一行。它拒绝 shell 和子系统会话，同时仍允许设备所需的转发，因此被盗的密钥无法变成交互式登录。 PermitListen 固定中心侧监听端的地址与端口，并且 GatewayPorts no 让它留在环回上，而不是向中心所在的网络开放。

重新加载前先测试生效配置，并在测试时保持第二个会话开着。 Match 块意外地对所有人生效，或选项名中有拼写错误，是把自己锁在正在加固的机器之外的经典方式。输出运行中的配置并重新读取选项，而不是相信刚写的文件。注意选项支持因版本而异，因此较新服务器接受的一行可能被较旧服务器直接忽略。

设备侧：会大声失败的转发

设备打开连接并请求监听端。参数中的两个地址 -R 含义不同，从左到右阅读是记住哪个是哪个的最快方式。

ssh -NT \
    -o ExitOnForwardFailure=yes \
    -o ServerAliveInterval=30 \
    -o ServerAliveCountMax=3 \
    -R 127.0.0.1:21022:127.0.0.1:22 \
    [email protected]

左边一对是中心应当监听的位置。右边一对是请求到达时设备所连接的目标，由设备自身一侧解析。把它们对调会得到一条干净起来却转发到错误位置的隧道，这比失败更糟。

ExitOnForwardFailure=yes 会在无法建立所请求的监听端时让命令退出，因此重启循环会告诉你真相，而不是留下半残的会话。它并不说明本地 SSH 服务之后是否健康，所以要配合进程管理器和偶发的真实连接测试。

绝不要为了省一跳而把环回监听地址换成通配地址。这一处改动就是管理通道与公网可达端口之间的差别，而且它通常发生在调试期间然后被保留下来。如果同事无法通过中心访问该端口，就修正跳板配置，而不是放宽绑定。环回正是这个设计的全部安全论证。

通过中心的管理员访问

在中心上有普通账户的管理员可以经中心跳到被转发的端口。中继账户不用于此，这正是把两者分开的意义。

ssh -J [email protected] -o HostKeyAlias=device-7 \
    -p 21022 [email protected]

在你选定的别名下校验设备的主机密钥，因为该密钥标识链条末端的设备，而隧道只是传输通道。端到端登录仍然认证两端；终止在共享中心上的隧道本身并不会让它成为可信路径。

掌握生命周期

在进程管理器下运行设备命令，保持恰好一个活动实例，并使用你刻意选择的重新启动策略。保活选项能发现已死的对端；它们不会复活已经退出的进程。

然后写下退役流程。每台设备都有自己的监听端和自己的密钥，因此退役意味着吊销那个账户并删除那把密钥，而不是轮换全舰队共享的机密。

最后，请记住环回给你带来了什么。它限制了网络暴露，却对共享中心上的其他本地用户毫无作用，所以中心自身的访问策略仍然必须正确。 sshd_config 参考 记录了上面用到的每一个选项，在放宽其中任何一个之前，值得把转发相关章节完整读一遍。

相关文章