dsh-web-ui 安全使用指南：配对门、隧道与 SSH 的 6 条安全建议-育师

dsh-web-ui 安全使用指南：配对门、隧道与 SSH 的 6 条安全建议

【免费下载链接】dsh-web-uiPlugin and skin collection for DeepSeek Harness (DSH) Web UI - task board, git graph, right-side panel, remote mobile UI, pet, live token stats, and skin center.项目地址: https://gitcode.com/gh_mirrors/ds/dsh-web-ui

DeepSeek Harness（DSH）Web UI 的插件与皮肤全家桶dsh-web-ui功能很强大：任务看板、Git 图谱、侧边栏、移动端远程控制、宠物、实时 Token 统计，还有皮肤中心。但功能越多，安全入口也越多——尤其是移动端远程控制的扫码配对、公网隧道和SSH 连接这三条通道，一旦配置不当，就可能把整个工作区暴露在网络上。这篇 dsh-web-ui 安全使用指南，为新手梳理 6 条实用安全建议，让你在享受远程控制便利的同时，把风险降到最低。

dsh-web-ui 安全基础：先认清三个入口

dsh-web-ui 的安全重点集中在三个模块：

配对门（Pairing Gate）：位于packages/dsh-remote-web-ui，负责移动端扫码配对的准入控制。
隧道（Tunnel）：同一插件内置 Cloudflare 快速隧道，用于把本机 Web UI 暴露到公网。
SSH 引擎：位于packages/dsh-ssh，管理主机连接、密钥、密码与端口转发。

理解这三者的安全模型，是后续 6 条建议的前提。

建议一：保持配对门开启，让二维码成为局域网唯一入口

dsh-web-ui 的移动端远程控制采用扫码配对：桌面端生成一次性令牌（Token），手机扫码后获得一个 HttpOnly 设备 Cookie。核心安全开关是requirePairingForLan，默认开启——此时每一个非本机回环（loopback）的 /api 请求都必须携带有效的已配对设备 Cookie，否则直接 403。

这个设计的妙处在于：即使你的 DSH 服务以--host 0.0.0.0暴露在局域网，未配对设备也什么都访问不了。请在设置中保持该开关开启，这是 dsh-web-ui 安全的第一道也是最重要的一道门。相关实现可查阅packages/dsh-remote-web-ui/src/gate.ts。

建议二：用完即停，及时撤销已配对设备

配对令牌是一次性且会过期的：刷新二维码会立即使旧链接失效，一个令牌只能被第一台设备成功使用。更关键的是桌面端的**「停止」按钮**——它会在瞬间撤销所有已配对设备会话并清空令牌，已配对的手机在下一个请求就会被切断（403）。

所以用完移动端远程控制后，请随手点击停止。哪怕设备暂时不用，也建议隔一段时间刷新二维码、检查已配对设备数量。所有配对状态都能在packages/dsh-remote-web-ui/src/pairing.ts中看到完整的安全不变量设计。

建议三：谨慎使用公网隧道，认清 trycloudflare 的公开性

开启autoTunnel后，dsh-web-ui 会自动启动 Cloudflare 快速隧道（Quick Tunnel），铸出一个https://xxx.trycloudflare.com的公开地址——无需账号、无需域名，免费且匿名。但请注意：这个地址是公网的，任何拿到链接的人都能加载到静态页面。

真正保护数据的是配对门（建议一）。不过你仍应意识到两点：一是 Quick Tunnel 的 hostname 每次重启都会变化，如果配合手动隧道使用，需要同步更新publicBaseUrl与--trusted-host；二是快速隧道不转发 Server-Sent Events（SSE），移动端实时消息会退化为轮询。相关逻辑见packages/dsh-remote-web-ui/src/tunnel.ts。

建议四：SSH 主机配置是敏感文件，注意保管与权限

dsh-ssh 插件把主机信息（含密码、密钥口令）明文保存在~/.dsh/dsh-ssh.json，这与 ssh-skill 的信任模型一致。虽然文件写入时会设置目录 0700、文件 0600的权限并采用原子写入，但它依然是敏感文件：

不要把这个路径暴露给模型、日志或截图。
不要让 SSH 执行结果原样回流到对话中（比如env可能带回远端环境密钥）。
定期检查主机列表，删除不再使用的条目。

存储逻辑位于packages/dsh-ssh/src/store.ts。

建议五：优先使用密钥认证，而非密码

dsh-ssh 支持两种认证方式：密钥（private key + 可选 passphrase）和密码。强烈建议优先使用密钥认证，并给私钥设置 passphrase。插件还支持从~/.ssh/config一键导入已有主机，自动识别IdentityFile与ProxyJump（跳板机），导入后原有的安全习惯可以无缝延续。

多主机批量执行（cluster）时，请务必确认目标列表，避免一条命令在几十台机器上同时执行。认证构建逻辑见packages/dsh-ssh/src/engine.ts。

建议六：注意端口转发隧道只绑定本机回环

dsh-ssh 的本地端口转发隧道（port-forward）设计上只监听127.0.0.1，不会对外网开放——这是一个很稳妥的安全默认值。使用隧道时请注意：

远端端口默认指向远端127.0.0.1，需要访问远端其他主机时记得显式指定remoteHost。
隧道停止时会同时关闭监听器、活动套接字并释放连接池，用完请及时关闭，避免长期占用。
通过隧道暴露本地服务给其他机器时，务必确认防火墙规则，不要让回环监听变成实际对外的入口。

总结：dsh-web-ui 安全的黄金三原则

回顾这 6 条建议，其实可以浓缩成三句话：配对门常开、隧道慎用、密钥管好。dsh-web-ui 的安全设计（一次性令牌、HttpOnly 设备 Cookie、逐请求撤销、回环绑定）已经做得相当周到，你要做的只是不主动关闭这些保护、及时撤销旧设备、妥善保管 SSH 凭据。遵循这份指南，你就能安心享受移动端远程控制、公网访问与多主机管理的全部便利，而不必担心安全敞口。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考