Windows环境反向隧道疑问：无OpenSSH Server时plink能否正常工作？

这个方案肯定没法正常工作，原因其实很直白：

核心逻辑的问题 #

你在PC_A上执行的plink.exe -R 12345:localhost:22 root@PC_B，本质是建立一条反向隧道：把PC_B的12345端口，转发到PC_A的localhost:22——而这个22端口，是OpenSSH Server默认的监听端口。

如果PC_A没装OpenSSH Server，那localhost:22这个端口根本没有任何服务在等着处理连接请求。当你在PC_B上跑ssh -p 12345 localhost时，请求会通过隧道传到PC_A的22端口，但那边完全没人响应，连接直接就失败了，更别提后续从PC_C访问PC_A的文件了。

替代方案（不用装OpenSSH Server的情况） #

如果不想在PC_A上部署OpenSSH Server，想要实现从PC_C访问PC_A文件的需求，可以试试这些思路：

• 利用Windows自带的SMB共享：把反向隧道指向PC_A的SMB端口（默认445），命令改成plink.exe -R 12345:localhost:445 root@PC_B。之后PC_C可以通过PC_B的12345端口，访问PC_A上的SMB共享文件夹（注意要提前在Windows里开启共享，并且防火墙允许SMB的入站请求）。
• 使用轻量反向文件传输工具：找一些不需要在PC_A装服务端的反向代理/文件传输工具，这类工具通常会自带客户端监听逻辑，不需要依赖系统级的服务。

内容的提问来源于stack exchange，提问作者user3013157