← 返回列表
未验证
为自托管主机加上登录验证,安全开放远程管理界面
尚未跑自动兼容性验证,可查看页面内的依赖与入口分析。 · 最近上游提交 2026/8/23 · 已提供中文文档
🐋 我的 DeepSeek Harness 环境,以代码形式部署和管理
综合分
28.3
GitHub 分
28.3
用户评分
—
★ Stars
1
周下载量
—
安装插件(需先安装 dsh CLI 引擎:npm install -g @deepseek-ai/dsh)
dsh plugin --profile web add nbsp1221/dotdsh该插件未发布到 npm,走 GitHub 源安装(pnpm 若拦截 prepare 脚本,按其提示在 pnpm-workspace.yaml 的 allowBuilds 中放行后重跑)
数据截至 2026/9/16(元数据每日更新 · 实装验证按队列轮转,单条结论的验证时间见上方)
依赖的 DSH / Cordis 模块
@deepseek-ai/dsh用户评分
还没有人投票,来当第一个
订阅周报,不错过优质插件更新
每周一封 · 高评分插件 + 新用户活动
README
dotdsh
个人 DeepSeek Harness 主机设置,带首次运行所有者身份验证。
该仓库记录了 DSH 如何构建、认证和监管。用于标识某一服务器的值保留在被忽略的主机补丁中,因此同一份检出可以在另一台机器上独立配置。
架构
public origin
-> external reverse proxy
-> configured auth proxy host:port
-> DSH 127.0.0.1:
内置的 DSH webserver 保持在回环地址上。只有 @dotdsh/dsh-auth 接受外部 HTTP、API 和 WebSocket 流量。
经过身份验证的用户会有意获得与本地 DSH 浏览器相同的完全管理员界面。dsh-auth 仍然是安全边界;那些小的客户端兼容性补丁只是告知内置 UI 消费者,经过身份验证的远程页面可以使用主机作用域设置和主机文件操作。
patches/ 下的文件是针对 DSH 0.1.1-rc.2 的精确版本 pnpm 补丁。当上游客户端发生变化时,它们会让升级失败关闭(fail closed)。pnpm check:compat 还会扫描已安装的 Web 组合,以查找仍以 connection.isLoopback 作为主机管理员功能门控的新 UI 消费者,因此每次 DSH 升级都必须通过该检查,才能刷新其补丁。
主机配置
创建被忽略的主机补丁:
cp config/host.patch.example.yml config/host.patch.yml
$EDITOR config/host.patch.yml
配置:
- publicOrigin:浏览器中使用的确切 HTTPS 源;
- host:如果反向代理在主机上,则为 127.0.0.1;如果容器化的反向代理必须访问主机,则为 0.0.0.0;
- port:由认证代理占用的主机端口。
会话生命周期和登录限流等身份验证策略仍保留在插件默认值中进行版本管理。密码状态和主机值不被跟踪。
安装
要求:
- 带有用户 systemd 管理器的 Linux;
- 当前 shell 可用的 node 和 pnpm;
- 当服务必须在登录前启动时,启用用户 lingering。
如果 lingering 被禁用,请启用一次:
sudo loginctl enable-linger "$USER"
从任意工作目录安装:
/path/to/dotdsh/scripts/install
安装程序会:
1. 推导检出目录、用户、Node、DSH home 和 XDG 配置路径;
2. 安装锁定的依赖树,构建认证插件,并验证 DSH 兼容性;
3. 将插件链接到当前 DSH Web 配置文件中;
4. 验证 config/host.patch.yml;
5. 渲染并验证用户 systemd 单元;
6. 启用并重启 dsh.service。
在移动检出目录或更改 Node 安装后,请重新运行安装程序,以便渲染出的单元获得新路径。
首次运行身份验证
打开配置的 publicOrigin。在没有所有者状态时,认证代理仅暴露密码设置表单。密码仅以 scrypt 哈希形式持久化在 ${DSH_HOME:-$HOME/.dsh}/auth/state.json 下。
设置完成后,每个页面、API 请求和 WebSocket 升级都需要安全会话 cookie。重启服务会清除会话,但会保留所有者密码。
验证
pnpm check:compat
pnpm check:config
systemctl --user status dsh.service
journalctl --user -u dsh.service
要直接检查未认证的 HTTP 边界,请替换 config/host.patch.yml 中的主机和端口:
curl -I -H 'Host: dsh.example.com' http://127.0.0.1:3080/
响应应该是设置或登录界面,绝不能是未受保护的 DSH
应用程序。
反向代理
对于直接在同一主机上运行的反向代理:
dsh.example.com {
reverse_proxy 127.0.0.1:3080
}
对于 Linux 容器中的 Caddy,将认证代理绑定到 0.0.0.0,在防火墙上限制该端口,并通过主机网关进行路由:
dsh.example.com {
reverse_proxy host.docker.internal:3080
}
容器可能还需要:
extra_hosts:
- "host.docker.internal:host-gateway"
反向代理配置不在本仓库范围内。
操作
systemctl --user restart dsh.service
systemctl --user stop dsh.service
systemctl --user start dsh.service
迁移到另一台主机
1. 克隆仓库;
2. 创建该主机被忽略的 config/host.patch.yml;
3. 如需要,启用 lingering;
4. 运行 scripts/install;
5. 在新主机上完成首次运行的密码设置。
认证状态有意保留在主机本地。仅在需要保留相同所有者密码时,才单独复制它。
移除
systemctl --user disable --now dsh.service
rm "${XDG_CONFIG_HOME:-$HOME/.config}/systemd/user/dsh.service"
systemctl --user daemon-reload
移除后,DSH 配置文件和所有者密码状态会保持不变。扫码进群