适用场景：Windows 实验室训练机、内网环境、个人主机稳定远程 SSH 接入
这次要连接的是一台实验室 Windows 训练机，，配置为双RTX 5090。机器本身已经开启了 OpenSSH Server，最初我们希望直接通过实验室内网地址连接：10.195.63.48:22
一开始 SSH 能用，但后面频繁出现从外部连接超时。经过排查，问题不是 sshd 服务坏了，而是外部到实验室内网的访问路径不稳定。也就是说，机器本地 SSH 是正常的，但“外面打进去”不稳定。
先确认实验室机 SSH 本身正常
在实验室机上先检查 sshd 服务：
sc query sshd
正常状态：
STATE : 4 RUNNING
再看 22 端口是否监听：
netstat -ano | findstr :22
正常：
TCP 0.0.0.0:22 0.0.0.0:0 LISTENING TCP [::]:22 [::]:0 LISTENING
最后在实验室机本机测试 SSH：
ssh admin@127.0.0.1
这一步能登录，说明 OpenSSH 服务、账号、密码都没有问题。后续外部连不上，重点怀疑网络路径、防火墙、安全软件或虚拟网卡入站策略。
直接 SSH 为什么不稳定
实验室机的内网地址 10.195.63.48 属于私有/校园内网地址。它能否被外部主机直接访问，取决于当时的路由、网关、防火墙和校园网策略。
我们观察到：
ping 10.195.63.48 超时 ssh admin@10.195.63.48 超时
但实验室机本地：
sshd 正常 22 端口监听正常 127.0.0.1 SSH 正常
所以结论是：
SSH 服务没坏，坏的是跨网访问路径。
这也是后面要引入虚拟组网或反向隧道的原因。
尝试过的方案
方案一：Tailscale
Tailscale 的思路是让两台机器加入同一个虚拟局域网，然后通过 100.x.x.x 地址互相访问。
但这次本机 Tailscale 出现了后端异常：
503 Service Unavailable: no backend
服务看起来在运行，但 CLI 和本地后端通信不稳定，tailscale ip -4、tailscale up 经常无输出或卡住。卸载重装后仍然没有稳定可用的图形界面和后端状态。所以这次没有继续采用 Tailscale。
方案二：Pinggy 临时隧道
Pinggy 可以不需要公网服务器，直接由实验室机主动创建一个临时公网 TCP 隧道。
实验室机上执行：
ssh -p 443 -o ServerAliveInterval=60 -o TCPKeepAlive=yes -R0:127.0.0.1:22 tcp@a.pinggy.io
成功后返回：
tcp://xxxxx.run.pinggy-free.link:39863
然后外部主机尝试：
ssh -p 39863 admin@xxxxx.run.pinggy-free.link
这条路能成功生成临时隧道，但实际 SSH 握手阶段不够稳定，出现过：
Connection timed out during banner exchange
所以它适合临时救急，不适合作为长期训练机接入方案。
方案三：ZeroTier
ZeroTier 是这次最接近成功的方案。我们创建了一个虚拟网络：
Network ID: 76fc96e498dc
实验室机加入后拿到：
10.59.120.22
本机加入后拿到：
10.59.120.1
实验室机加入命令：
"C:\Program Files (x86)\ZeroTier\One\zerotier-cli.bat" join 76fc96
查看状态：
"C:\Program Files (x86)\ZeroTier\One\zerotier-cli.bat" info "C:\Program Files (x86)\ZeroTier\One\zerotier-cli.bat" listnetworks
正常时可以看到：
200 info 57b2e3bc 1.16.1 ONLINE 200 listnetworks 76fc96e498d8 my-first-network ... 10.59.120.22
网页后台需要把两个节点都勾选 Authorized。这一步很重要，否则本机或实验室机可能 join OK，但拿不到虚拟 IP。
ZeroTier 打通后的排查
ZeroTier 成功后，本机可以 ping 通实验室机：
ping 10.59.120.222
结果正常：
Reply from 10.59.120.222: bytes=32 time=13ms TTL=57
但 SSH 仍然超时：
ssh admin@10.59.120.222
结果：
ssh: connect to host 10.59.120.222 port 22: Connection timed out
这说明三层网络已经通了，但 TCP 入站被拦。
在实验室机上确认 sshd 监听：
netstat -ano | findstr :22
确认 ZeroTier 网卡：
powershell -Command "Get-NetAdapter | Format-Table Name,InterfaceDescription,InterfaceIndex,Status -AutoSize"
确认网络类型：
powershell -Command "Get-NetConnectionProfile | Format-Table Name,InterfaceAlias,InterfaceIndex,NetworkCategory -AutoSize"
我们把 ZeroTier 网卡改成了 Private：
powershell -Command "Set-NetConnectionProfile -InterfaceIndex 43 -NetworkCategory Private"
并添加了防火墙规则：
netsh advfirewall firewall add rule name="OpenSSH-ZeroTier-TCP22-Subnet" dir=in action=allow protocol=TCP localport=22 remoteip=10.59.120.0/24 profile=any
powershell -Command "New-NetFirewallRule -DisplayName 'OpenSSH-ZT-Program-Subnet' -Direction Inbound -Action Allow -Program 'C:\Windows\System32\OpenSSH\sshd.exe' -Protocol TCP -LocalPort 22 -RemoteAddress 10.59.120.0/24 -Profile Any"
为了确认是否是 Windows 防火墙导致，还短暂关闭过防火墙：
netsh advfirewall set allprofiles state off
但本机访问 10.59.120.222:22 仍然超时。
这说明问题不在 Windows 自带防火墙规则，而更可能是第三方安全软件、HIPS、EDR 或网卡过滤驱动。
换端口验证
为了排除 22 端口被特殊拦截，我们把 OpenSSH 增加了一个新端口 2222。
编辑：
C:\ProgramData\ssh\sshd_config
添加：
Port 22 Port 2222
重启服务：
sc stop sshd & sc start sshd
确认监听：
netstat -ano | findstr :2222
结果：
TCP 0.0.0.0:2222 0.0.0.0:0 LISTENING TCP [::]:2222 [::]:0 LISTENING
但本机连接：
ssh -p 2222 admin@10.59.120.222
仍然超时。这进一步说明：
不是 22 端口本身的问题，而是实验室机对 ZeroTier 虚拟网卡的 TCP 入站有更底层的拦截。
管理员公钥路径的坑
Windows OpenSSH 有一个容易踩的坑。
C:\ProgramData\ssh\sshd_config 里有这段：
Match Group administrators AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys
admin 属于 Administrators 组时，公钥不会读：
C:\Users\admin\.ssh\authorized_keys
而是读：
C:\ProgramData\ssh\administrators_authorized_keys
所以如果后续要配置免密登录，公钥应该放到：
C:\ProgramData\ssh\administrators_authorized_keys
并确保权限正确。
推荐的标准接入流程
下一次从零配置，推荐按这个顺序走。
第一步：确认实验室机 SSH 正常
sc query sshd netstat -ano | findstr :22 ssh admin@127.0.0.0
只要本机回环 SSH 能进，就说明 sshd 没问题。
第二步：两台机器加入 ZeroTier
安装 ZeroTier 后，两台机器都执行：
"C:\Program Files (x86)\ZeroTier\One\zerotier-cli.bat" join 76fc96e498
然后到 ZeroTier 网页后台授权两个节点。
检查：
"C:\Program Files (x86)\ZeroTier\One\zerotier-cli.bat" listnetworks
两台机器都应拿到 10.59.120.x/24 这样的地址。
第三步：确认网络互通
在本机：
ping 10.59.120.22
如果 ping 通，说明 ZeroTier 网络层已经通。
第四步：放行 SSH 入站
在实验室机管理员 cmd：
netsh advfirewall firewall add rule name="OpenSSH-ZeroTier-TCP22-Subnet" dir=in action=allow protocol=TCP localport=22 remoteip=10.59.120.0/24 profile=any
netsh advfirewall firewall add rule name="OpenSSH-2222" dir=in action=allow protocol=TCP localport=2222 profile=any
第五步：如果 ping 通但 SSH 超时
如果出现：
ping 通 ssh 超时 Windows 防火墙关闭后仍超时 22 和 2222 都超时
基本可以判断为第三方安全软件或底层过滤驱动在拦截虚拟网卡入站 TCP。
这时应检查：
tasklist | findstr /i "hips security firewall defender endpoint edr"
也可以在任务管理器里查看是否存在主机防护、HIPS、EDR、安全管家、校园网安全客户端等进程。
如果能临时关闭网络防护，再测试：
ssh admin@10.59.120.222
最终结论
这次排查可以总结成一句话：
实验室机 SSH 服务本身是正常的，ZeroTier 也已经把两台机器连到了同一个虚拟网；真正阻塞的是实验室机对 ZeroTier 虚拟网卡的 TCP 入站访问。
所以后续最推荐的稳定方案是：
ZeroTier 负责组网 OpenSSH 负责远程命令行 实验室机安全软件需要明确放行 ZeroTier 网卡上的 TCP 22/2222
如果实验室机安全策略无法放开入站 TCP，备用方案是：
使用公网跳板机做反向 SSH 隧道
但这需要一台可公网访问的服务器。没有公网服务器时，ZeroTier 仍然是当前最接近长期可维护的方案。
当前项目里的实际状态
本次项目中，训练已经不依赖远程 SSH 才能继续。实验室机上的新版 6 类训练已经启动：
E:\yolo26-kuangqu\ultralytics-main
训练日志：
E:\yolo26-kuangqu\ultralytics-main\train_run.log
当前命令：
python train_mining.py --config config\train_config_expanded6_clean_refresh_heqselect_v1_5090_m_strategyfirst.yaml > train_run.log 2>&1
远程连接排障和训练可以分开处理：训练先跑，远程接入后续继续优化。这样不会因为网络问题耽误模型实验。
