安全组别把出网堵死，直连不用开放入站

远程接入类插件最容易在云上被配错的地方，不是少了哪条规则，而是多了一条。dsh-tether 把 DSH 的 Web 界面通过 iroh 点对点送到手机，链路是两端主动向外建立的，所以治理重点和传统反向代理完全不同：入站只留运维用的 SSH，出站必须留活口。这篇按「网络与权限治理」的角度，把一台阿里云 ECS 上的可执行口径写清楚。

先回答三个治理问题

• 谁能连进来：只有完成配对的手机。配对靠 6 位 CSPRNG 码，有效期 10 分钟，每个窗口 3 次尝试；配对之后访问权由手机的 iroh 公钥决定，iroh 的 TLS 会校验它。
• 流量经过谁：打洞成功时两端直连，不经过第三方；打洞失败才回退到中继，而中继只承载它读不懂的密文。
• 该开哪个端口：插件本身一个都不用在入站开。这是本文最需要向安全评审解释清楚的一点。

安全组：入站只留 SSH，出站按需

阿里云安全组默认出站全通。真正出问题的是「按最小权限收紧出站」之后只补了 443，忘了 UDP。

UDP 之所以不能写死某个端口：打洞用的是协商出来的端口，不是固定服务端口。你没法用「只放行某一个 UDP 端口」的方式把规则收窄，只能按协议放行。如果合规要求必须收窄目的地址，那就落到「这台 ECS 只允许访问模型 API 域名对应的地址段」这一层，而不是去猜端口。

除 SSH 之外，入站不需要任何规则，因为没有任何一方在等入站连接。再开一个自定义端口，唯一效果是把暴露面变大。

出站被堵的两个典型症状

• 配对后一直停在连接中：配对码生成正常、手机也进了列表，但连接建立不起来，实例侧日志全是超时。先查安全组出站，再查宿主版本。
• 能连上但一会儿就断：多数不是安全组，而是 App 本身不保持后台连接——它打开时才连，Android doze 也不允许常驻。这类现象换网络、加规则都不会好，属于预期行为。

把这两类分开很重要：前者是配置问题，后者是设计边界。混在一起排查，会不停地在安全组上做无用改动。

公网 IP 不是前提，打洞失败是例外

不需要固定公网 IP、不需要自建 relay、也不需要两端在同一个 Wi-Fi——这是它和「同 Wi-Fi 直连」「自建 Tailscale」两类方案的分界。云上要满足的只有出网能力。

但这条优势有个前提条件必须写进评审材料：打洞失败会回退到中继，而中继路径从未在真实网络中被触发过，延迟表现没有任何实测数据。可引用的证据只有直连那条路径——手机 Wi-Fi 关闭只留 5G、机器在家宽，插件在选定路径上报出公网地址。所以规划时把它当「通常直连、偶尔兜底」，不要当「必然直连」。

共享机器上，两道门各挡一半

插件在机器侧有两条 HTTP 路由，沿用 dsh 对 /api 的浏览器信任规则：Host 必须是 loopback、拒绝显式跨站标记、Origin 必须匹配 Host。恶意页面的跨站请求和 DNS rebinding 都会拿到 403，这一层挡的是「浏览器被当成替身」。

它挡不住本机进程。本机进程可以给出 loopback 的 Host，自己生成一个配对码并把自己配成一部手机，于是「能在这台机器上执行代码」就变成了长期访问。结论很直接：不要在这台机器上跑不可信代码。

手机侧还有一道独立的边界：本地代理只监听 127.0.0.1，但手机上任何其他 App 都能连上它并拿到完整界面，端口又是由 host 推导出来的，比随机端口更好猜。手机装了不可信 App，或者手机落到别人手里，等价于把开发机交出去。

两条边界合起来给出一条运维规则：接入端和被发现端都要是「你自己独占」的设备。共享构建机、多人共用的跳板机、演示用手机，都不适合作为这条通道的两端。

配对码的运维纪律

• 有效期 10 分钟、每个窗口 3 次尝试，这是硬约束，不要试图「延长一点方便同事」。
• 一个码对应一次配对动作。要给第二部手机接入，在电脑端重新生成一个新码，不要转发旧码。
• 配对码是文本，会出现在截图、聊天记录和工单里。把它当临时凭证对待：发出去之后立刻用掉，过期就当它已泄露。
• 换机器或换手机，先用手机侧边栏底部的「My computers」清理旧条目，再在电脑端生成新码重新配对；电脑端随时可以出新码。

多机管理与环境隔离

手机侧边栏底部的「My computers」可以切换、重命名、移除和新增机器，换机器不用重输凭证。治理上建议把命名规则固定下来，比如 环境-用途-地域，别用「测试机 2」这种半年后没人认得的名字。

生产 ECS 与个人开发机不要用同一部手机混着连——不是技术限制，是操作事故的常见来源：在错误的机器上批准了一次高危工具调用，事后只能从日志里还原。要混用，就至少让命名一眼能区分。

日志、凭证与截图

• 配对用的那行文本、手机公钥、dsh web 的会话内容，都不要贴进公开 Issue。
• 提 Issue 时给的是版本号与现象，不是整段日志。日志里可能带路径、内网地址和模型返回内容。
• 这台机器上的 API Key 走宿主的配置，不要为了「让手机也能调」把它抄到别处；手机侧连的是同一个界面，不需要第二份凭证。
• 安全扫描的档位是「🔵 含敏感能力」，5 处证据覆盖可执行外部命令、读写删除本地文件、发起外部网络请求；尚无人工评估，本站也尚未做风险分级。写进评审材料时按这个口径引用，不要简化成「安全」或「高风险」。

上线前检查表

总结

这套方案的治理成本比反向代理低：入站不用为它开，公网 IP 不用绑，要守的只有出站放行、宿主版本和两端设备的独占性。真正需要提前讲清楚的例外是打洞失败后的中继路径没有实测数据；更多同类插件的中文清单见 DeepSeek Harness Hub 插件清单。

适合与不适合

适合：需要给远程接入做安全评审、要一份可执行的最小权限口径；DSH 跑在云上 ECS、人用手机盯进度；团队里有多台机器需要统一命名与回收；不接受自建 relay 或内网穿透服务。
不适合：安全组必须收窄到固定端口才合规的环境；机器上要跑不可信代码或多人共用；需要 7×24 稳定远程桌面级可用性；手机端本身不是可信设备。

标签：dsh-tether、DeepSeek Harness、阿里云安全组、最小权限、远程接入

本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。