我正在尝试使用一种远程访问方法（开源），该方法涉及 openssh 和 tightvnc，可以处理 NAT，允许某人远程访问我的服务器，然后允许我通过 vnc 返回他们的机器，而无需干扰他们的防火墙，并允许我在以后使用静态 WAN 地址。我一直在尝试通过小步骤粗略地解决这个问题，以管理未知因素（对我来说，很多：）。看起来其他人已经让这个工作正常了，但我却不知所措。
首先，我已经在我的笔记本电脑上实现了两个 Windows 10 虚拟机（hyperv）之间的无密码反向 ssh 工作（即，我还没有尝试处理防火墙上的端口转发或静态 WAN 地址），但无法让 vcn 通过反向 ssh 隧道工作，尽管它只使用 lan IP 地址而不是“localhost”进行反向 ssh 就可以了。
我想知道我的整体方法是否有缺陷。它是：
机器 A/人员 A（需要帮助）
目前是 win10 vm
ssh 客户端（win10 原生）
tightvnc 服务器
机器 B/人员 B（服务台角色）
目前为 win10 vm（目前与机器 A 位于同一 LAN）
ssh 服务器（可选 win10 附加组件）
tightvnc 客户端
这个想法是，机器 A 上的人员 A 启动机器 A 上的 VNC 服务器，并通过反向 ssh 连接到机器 B（目前一切顺利）。此时，机器 B 上的人员 B 可以通过 VNC 返回机器 A 并提供帮助。
我假设问题可能是使用从 A->B 的反向 ssh（我也尝试了 -L 选项而不是 -R），然后使用 tightvnc 从 B 访问机器 A。在机器 A 上启动 vnc 服务器后，我从 A 到 B 使用的初始 ssh 命令示例是：
ssh -R 5902:localhost:5901 user@lanaddressMachineB -i ~/.ssh/id_rsa -vv
这部分工作正常。A 上的 vnc 服务器有端口 5902（我已打开和关闭环回，尝试监听服务器）。我希望这是类似于我对哪个是本地主机感到困惑之类的事情。
当我尝试使用“localhost::5902”通过 ssh 隧道将机器 B 连接到机器 A 时，出现的错误是“连接已正常关闭”。如果我从 B 使用 A 上的 vnc 服务器的 lanip，vnc 连接就可以正常工作。
客户端和服务器上的“tviewer.log”中没有任何内容。我尝试更改 sshd_config 中的某些设置（例如，AllowAgentForwarding yes），但没有结果。
问：我的设计有缺陷还是可行？这是我配置事物的方式吗？是否可以解决，可能使用不同的 ssh 命令？
Q 我是否需要在两台机器上都安装 ssh 服务器（希望避免这种情况，因为这意味着必须在其他人的机器上安装它）？
我知道这一切有各种付费的和一些免费的选择，但我希望能让它继续下去。
谢谢。
答案1
在处理 Windows 上的 SSH 端口转发时，我们在工作中遇到了类似的问题。查看以下输出网络状态，确认 TightVNC 正在监听端口 5901：
PS C:\WINDOWS\system32> netstat -an | findstr 5901
TCP 0.0.0.0:5901 0.0.0.0:0 LISTENING
PS C:\WINDOWS\system32>
将其与内置远程桌面服务的监听套接字进行对比（我排除了与本讨论无关的 UDP 套接字）：
PS C:\WINDOWS\system32> netstat -an | findstr 3389 | findstr /V UDP
TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING
TCP [::]:3389 [::]:0 LISTENING
PS C:\WINDOWS\system32>
TightVNC 服务似乎没有实现双栈套接字（IPv4 + IPv6）。这很不幸，因为当 TightVNC 尝试通过 RemoteForward 隧道向后连接时，使用单个 SSH 客户端运行-v将显示以下消息：
debug1: client_input_channel_open: ctype forwarded-tcpip rchan 3 win 2097152 max 32768
debug1: client_request_forwarded_tcpip: listen localhost port 5901, originator 127.0.0.1 port 50132
debug1: getsockopt TCP_NODELAY: Invalid argument
debug1: connect_next: host localhost ([::1]:5900) in progress, fd=7
debug1: channel 1: new [127.0.0.1]
debug1: confirm forwarded-tcpip
debug1: channel 1: connected to localhost port 5900
debug1: channel 1: free: 127.0.0.1, nchannels 2
重要的是connect_next，它显示 OpenSSH 客户端正在尝试 IPv6 和仅有的代理连接时使用 IPv6。
我在 TightVNC 设置中找不到任何绑定 IPv4+IPv6 的选项，但这并不重要，因为有一个简单的解决方法。而不是这样：
ssh -R 5902:localhost:5901 user@lanaddressMachineB -i ~/.ssh/id_rsa -vv
尝试这个：
ssh -R 5902:127.0.0.1:5901 user@lanaddressMachineB -i ~/.ssh/id_rsa -vv
更令人困惑的是，localhost::5902在 TightVNC 客户端中输入是完全没问题的。这是因为 MachineB（端口 5902）上的 OpenSSH 侦听器是双栈的：
PS C:\WINDOWS\system32> netstat -an | findstr 5902
TCP 127.0.0.1:5902 0.0.0.0:0 LISTENING
TCP [::1]:5902 [::]:0 LISTENING
PS C:\WINDOWS\system32>
更新：读完您的回答后，我想确认我们在端口号方面是否意见一致。我的回答中的命令假设如下：
- 机器 A -> TightVNC 服务器 -> 主服务器端口 = 端口 5901
- 机器 A -> OpenSSH 客户端 -> RemoteForward 规范 =
-R 5902:127.0.0.1:5901 - 机器 B -> TightVNC 客户端 -> 远程主机 =
localhost::5902
具体来说，我认为您可能已经在端口 5902 上运行 TightVNC 服务器，尽管这与 RemoteForward 规范不匹配。
答案2
您提到“计算机 A”上的 VNC 服务器在端口 5902 上运行，并且您还尝试连接到“计算机 B”上的端口 5902 (localhost:5902) 以访问“计算机 A”的 VNC。您给出的示例：
ssh -R 5902:localhost:5901 user@lanaddressMachineB -i ~/.ssh/id_rsa -vv
是错误的。对于你正在做的事情，你应该使用：
ssh -R 5902:localhost:5902 user@lanaddressMachineB -i ~/.ssh/id_rsa -vv
-R 的第一个参数是远程（SSH 服务器）端的 sshd 将监听的端口，而第三个参数是本地 SSH 客户端将连接的端口（当有人连接到远程端的第一个参数端口时）。按照您的描述，您需要将端口设置为 5902。
修复该问题后，我看不出它为什么无法工作。