多用户网关 Mpaperlee/dsh-hub

dsh-hub

License: MIT
Node
Platform
dsh-8A2BE2.svg)

一个 JupyterHub 风格的 DeepSeek Harness (dsh) 多用户前端—— PAM 登录、每个系统用户一个隔离的 dsh 实例，以及基于 cookie 路由的 HTTP/WebSocket 代理。对 dsh 零修改：上游升级和每用户插件安装均不受影响。

中文简介:dsh-hub 是 DeepSeek Harness (dsh) 的多用户网关,思路完全对标
JupyterHub:服务器系统账号(PAM)登录,每个用户一个完全隔离的 dsh 实例
(独立 uid/gid、独立数据目录、iptables 端口防护),浏览器直接访问 http://:3080 即可使用。不修改 dsh 任何代码——上游升级、每用户自行安装插件均不受影响。

browser ──http://:3080──▶ dsh-hub ──cookie──▶ 127.0.0.1: ──▶ dsh (user A)
│ 127.0.0.1: ──▶ dsh (user B)
└─ spawn as uid/gid + iptables owner-guard

架构（JupyterHub 类比）

| JupyterHub | dsh-hub |
| Authenticator (PAM) | 通过 authenticate-pam 实现 PAM（可选），并带有基于 su 的回退方案；HMAC 签名的会话 cookie |
| Spawner | 以用户的 uid/gid 和每用户独立的 DSH_HOME 启动 dsh web --port |
| Configurable HTTP proxy | http-proxy 根据会话 cookie 路由 HTTP + WebSocket |
| Idle culler (jupyterhub-idle-culler) | 内置 culler，IDLE_CULL_MS（0 = 永不回收，tmux 风格的常驻） |
| Single-user server trusts the hub | 通过回环代理并配合 SameSite cookie 的 CSRF 防护（JupyterHub 的信任分离） |

信任模型

dsh 的 Web 服务器会强制执行浏览器信任围栏（Origin/Host 权威校验），
以防御 DNS 重绑定和 CSRF。dsh-hub 的代理（默认
TRUST_MODE=origin-rewrite）将自身呈现为回环同源客户端：
Host 和 Origin 会被重写为后端的回环权威，而跨站防护由 hub 的
SameSite=Lax 会话 cookie 承担——这正是 JupyterHub 在其代理与单用户
服务器之间使用的同一种信任分离。

TRUST_MODE=trusted-host 会使用 dsh 官方的
--trusted-host 标志启动实例，并原样转发 Host/Origin。注意：截至当前 dsh，RPC 主机对回环权威的 /api 通道会清空 trustedHosts，因此该模式仅在围栏确实消费该标志时有效（直接 LAN 绑定）。保留它是为了未来上游对代理部署的支持。

非安全上下文 polyfill

浏览器仅在安全上下文（HTTPS 或 localhost）中暴露 crypto.randomUUID()。在裸 http://:3080 上，dsh-hub 会向每个被代理的 HTML 页面注入一个自我防护的 v4-UUID polyfill（一旦 dsh 修复其剩余的直接调用，或者你通过 HTTPS 提供服务）。

远程设置（isLoopback 门控）

dsh 的设置/凭据平面（Settings → Models 页面）在浏览器端被门控为仅限
loopback 页面：connection.isLoopback 派生自 location.hostname，因此即使 hub 的 origin 重写已经通过了服务端的 loopback 防护， LAN 主机名页面仍会报告 settings are unavailable in this browser。
Location 成员是 [LegacyUnforgeable] 自有访问器——没有任何 polyfill 能伪造它们——所以 dsh-hub 改为在传输过程中重写连接插件包：
isLoopbackHostname(pageLocation.hostname) 变为 true。该补丁基于
dsh 未压缩包的模式匹配，按包修订版本缓存，并在上游升级重命名该表达式时
在 hub 日志中大声失败。
信任仍归属于 hub：只有经过 PAM 认证的用户才能访问后端，并且 SameSite=Lax 会话 cookie 仍会阻止跨站请求。

隔离保证（以 root 运行）

- 每个 dsh 实例以用户自己的 uid/gid 运行，并设置 DSH_HOME=~/.dsh
- 实例绑定 127.0.0.1:；一个 iptables owner-guard （loopback，--uid-owner）会 DROP 来自其他本地用户的连接
- 登录速率限制（5 次失败 → 每个 IP 锁定 1 分钟）
- 可选的 ALLOW_USERS 允许列表

快速开始

git clone https://github.com/Mpaperlee/dsh-hub.git /opt/dsh-hub
cd /opt/dsh-hub && npm install

dev run (no root: no setuid/iptables, single-user semantics)
DSH_BIN=/path/to/deepseek-harness/apps/cli/lib/bin.js HUB_PORT=3080 \
HUB_LOG_DIR=/tmp npm start

生产环境（root，systemd）：

sudo cp dsh-hub.service /etc/systemd/system/
sudo systemctl daemon-reload && sudo systemctl enable --now dsh-hub

用户浏览到 http://:3080，使用其系统用户名/密码登录，并获得一个私有的 dsh 实例。

配置

| 环境变量 | 默认值 | 含义 |
| DSH_BIN | （必填） | dsh CLI 入口（已构建的检出目录：apps/cli/lib/bin.js） |
| HUB_HOST / HUB_PORT | 0.0.0.0 / 3080 | hub 监听地址 |
| TRUST_MODE | origin-rewrite | trusted-host 原样转发 Host/Origin（参见上文的信任模型） |
| TRUSTED_HOSTS | 自动（LAN IPv4） | 用于 --trusted-host 的额外 authority（主机名/DNS 名称） |
| IDLE_CULL_MS | 14400000（4 小时） | 0 禁用清理——浏览器关闭后后端继续运行 |
| SESSION_TTL_MS | 7 天 | cookie 生命周期 |
| ALLOW_USERS | （全部） | 逗号分隔的用户名允许列表 |
| HUB_LOG_DIR | /var/log/dsh-hub | 每用户后端日志 |
| COOKIE_SECRET_FILE | ./.cookie-secret | HMAC 密钥（自动生成，0600） |

说明

- 对话在浏览器关闭后仍会保留：goal/服务端驱动会在生成的 dsh 进程中继续运行；重新登录会重新附加到同一实例。
- 配置更改后执行 sudo systemctl restart dsh-hub。
- 非 root 运行是降级（开发）模式：没有 setuid 生成，没有 iptables 防护。

许可证

MIT