折腾记录 on BINGBlog

把 dsh 挂上公网：两道闸与自动登录

Thu, 17 Sep 2026 17:00:00 +0800

dsh（DeepSeek Harness）是 DeepSeek 开源的 agent harness，有 CLI 也有 Web UI，默认只监听 127.0.0.1:3080，CLI 明确拒绝 --host 0.0.0.0。它自带启动 token 与签名 cookie 两道鉴权，但没有 TLS、没有账号体系，官方也把「网络部署」列为不支持。想在服务器上用，就得自己在前面架一层。下面是完整过程，机器是 Azure 上那台 892MB 的小 VPS。

一、为什么不能直接开出去

dsh 的 Web 宿主在 /api 前缀上有一道「浏览器信任栅栏」，代码注释写得很直白：它挡的是 DNS rebinding 和跨站请求，不是身份认证。

检查	规则
Host	必须是回环地址，或与 `--trusted-host` 声明的 authority 匹配
Origin（带了才查）	必须与 Host 完全一致
`sec-fetch-site`	`cross-site` 一律拒
POST 媒体类型	必须是 `application/json`，否则 415

认证是另一层：每个进程随机生成一个启动 token，只有 GET /?token=... 能把它换成签名 cookie（HttpOnly、SameSite=Strict、绑定 host:port、默认 30 天）。token 不落盘、每次启动都变；签名密钥存在 $DSH_HOME/.credentials.yaml，所以 cookie 能跨重启继续用。

两条结论直接决定反代怎么写：

Host 必须原样转发。写成 $host:443 会当场 403 —— 浏览器发来的 Origin 是 https://域名，归一化后不带端口，和 host:443 对不上。
必须传 --trusted-host <域名>，否则 /api 全部被 Host 栅栏拒掉。

二、安装与首启

sudo useradd -m -s /bin/bash dsh # 独立账号，不进 sudo 组
sudo npm i -g @deepseek-ai/dsh # 本次装到 0.1.5-rc.1

首次启动会从内置模板生成 profile（$DSH_HOME/profiles，要装一批插件依赖），所以第一遍慢一些：

sudo -u dsh env HOME=/home/dsh DSH_HOME=/home/dsh/.dsh \
 dsh web --port 3080 --no-open --trusted-host dsh-xxxx.你的域名

# dsh web: http://127.0.0.1:3080/?token=...

--no-open 不弹浏览器，--trusted-host 只扩信任栅栏，不给身份。

三、systemd 托管

机器只有 892MB 内存，必须给上限；再按 RCE 服务的标准一并做隔离：

# /etc/systemd/system/dsh-web.service
[Unit]
Description=DeepSeek Harness (dsh) Web UI
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=dsh
Group=dsh
WorkingDirectory=/home/dsh/workspace # 工作区就是启动目录
Environment=HOME=/home/dsh
Environment=DSH_HOME=/home/dsh/.dsh
EnvironmentFile=/etc/dsh/dsh.env # DEEPSEEK_API_KEY，600 root
ExecStart=/usr/bin/dsh web --port 3080 --no-open --trusted-host dsh-xxxx.你的域名
Restart=always
RestartSec=5

MemoryMax=800M
TasksMax=512

NoNewPrivileges=true
PrivateTmp=true
PrivateDevices=true
ProtectSystem=strict
ProtectHome=read-only
ReadWritePaths=/home/dsh
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectControlGroups=true
RestrictSUIDSGID=true
LockPersonality=true
CapabilityBoundingSet=
AmbientCapabilities=
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6 AF_NETLINK
UMask=0077

[Install]
WantedBy=multi-user.target

ProtectSystem=strict 把整个根文件系统挂成只读，唯一能写的是 ReadWritePaths 指定的 /home/dsh。systemd-analyze security dsh-web 实测 4.1 OK。

四、Key 走环境变量

内置的 llm-deepseek 适配器默认凭据引用就是 DEEPSEEK_API_KEY，用 systemd EnvironmentFile 注入：

# /etc/dsh/dsh.env（600 root:root）
DEEPSEEK_API_KEY=sk-xxxxxxxx

由环境变量供值的引用在 Web 设置里是只读的（writable: false），key 不进应用可写状态，轮换只要改这个文件加一次 restart。

五、公网入口

为什么用子域名

dsh 前端是标准 SPA，静态资源与 /api 都走绝对路径，用路径前缀反代要动一堆地方，cookie 的 authority 绑定也更绕。子域名最省事；没有域名就用 sslip.io：dsh-xxxx.<IP>.sslip.io 会解析到那个 IP，Let’s Encrypt 照签。

随机子域名本身当第一层"隐藏"：串不可猜。证书用 webroot 签，80 端口的 server 块只放行 ACME 校验：

location ^~ /.well-known/acme-challenge/ { root /var/www/html; auth_basic off; }

sudo certbot certonly --webroot -w /var/www/html -d dsh-xxxx.你的域名

# Basic Auth 账号，密码用 openssl 生成 apr1 哈希（服务器上没装 htpasswd 也能用）
printf 'dsh:%s\n' "$(openssl passwd -apr1 "$PASS")" \
 | sudo install -m 640 -o root -g www-data /dev/stdin /etc/nginx/.htpasswd-dsh

反代与限速

server {
 listen 443 ssl;
 server_name dsh-xxxx.你的域名; # 只有这个名字能进

 auth_basic "DeepSeek Harness"; # 第一道闸
 auth_basic_user_file /etc/nginx/.htpasswd-dsh;
 limit_req zone=dsh_zone burst=120 nodelay;
 client_max_body_size 100m;

 location / {
 proxy_pass http://127.0.0.1:3080;
 proxy_http_version 1.1;
 proxy_set_header Host $host; # 不带端口，理由见第一节
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection $connection_upgrade;
 proxy_buffering off; # SSE / 流式必需
 proxy_read_timeout 3600s; # 长任务别被 60s 掐断
 proxy_request_buffering off;
 }
}

六、第二道闸的坑

只过 Basic Auth 会被 dsh 自己挡住：

dsh web authentication required; reopen the URL printed by dsh web.

这是启动 token 那道闸。手动过的话，从服务日志里捞当前进程的 URL：

journalctl -u dsh-web -o cat | grep -o 'token=[A-Za-z0-9_-]*' | tail -1

两个容易踩的点：

上游返回的 401 不会触发 error_page：nginx 默认 proxy_intercept_errors off，只拦自己产生的错误码，要在这个 location 里显式打开
map $http_upgrade $connection_upgrade 得定义在 http 块；漏了 WebSocket 升级会失败，页面上表现为一直转圈

七、让闸门无感

token 每进程都在 journal 里，可以让 nginx 自己拿它换 cookie：首页拿到 401 时内部重试一次带 token 的请求，把 303 + Set-Cookie 原样透给浏览器。浏览器地址栏全程不带 token，比手动粘贴 URL 更干净。

location = / {
 error_page 401 = @dsh_login;
 proxy_intercept_errors on; # 关键：否则不触发 error_page
 proxy_pass http://127.0.0.1:3080;
}

location @dsh_login {
 proxy_pass http://127.0.0.1:3080/?token=$dsh_launch_token;
}

$dsh_launch_token 由一个小脚本同步：从 journal 取当前进程 token，写进 /etc/nginx/conf.d/dsh-token.conf 里的 map，再 reload nginx。挂到服务启动钩子上，重启后 token 自动跟上：

# /etc/systemd/system/dsh-web.service.d/token-sync.conf
[Service]
ExecStartPost=+/usr/local/bin/dsh-token-sync # + 前缀 = 以 root 跑，才能读 journal、reload nginx

代价要说清楚：这样一来对外实际只剩 Basic Auth 一道闸，加上它前面的随机子域名。想恢复两道闸，屏蔽掉内部重试即可：

sudo touch /etc/dsh/auto-login.off && sudo dsh-token-sync --now # 关
sudo rm /etc/dsh/auto-login.off && sudo dsh-token-sync --now # 开

八、验证

鉴权矩阵，全部从公网入口测：

请求	结果
无 Basic Auth	401
密码错误	401
Basic Auth、无 cookie	303 + Set-Cookie（自动登录）
Basic Auth、带 cookie	200
直连 `127.0.0.1:3080` 并伪造 `Host: localhost`	401（信任栅栏与 cookie 双查）

最后用无头浏览器跑一轮真实任务，确认 /api、工具调用、模型都通：

九、隔离与限制

同机隔离：dsh 能执行任意命令，这台机器上还跑着网关和博客，它的进程不该读到后者的凭据。除 ProtectHome=read-only 外再补一条 ACL，把整个家目录对它关掉：

sudo setfacl -m u:dsh:--- /home/你的用户 # 撤销：sudo setfacl -x u:dsh /home/你的用户

同机其他服务的家目录里若有 world-readable 的凭据文件（~/.cli-proxy-api/config.yaml、~/.pi、~/.codex），一并收成 700。

设置页在非回环访问下不可用：客户端会判断页面自身是不是 loopback，不是就把设置持久化降级成内存（源码里是 isLoopback ? 'host' : 'memory'），于是「设置 → 模型」直接报 settings are unavailable in this browser。模型与凭据都改服务端文件：

# /home/dsh/.dsh/settings.yaml，改完下一次请求生效，不用重启
llm-deepseek:
 reasoningEffort: high

公网暴露 RCE 的现实：过了 Basic Auth 就是一个能跑命令的 agent。密码用 24 位随机串、限定单域名、开限速，能做的都做了；要更稳就关掉自动登录，只用一次性 token URL 进。

小结

dsh 默认只回环，反代要原样转发 Host 并传 --trusted-host，否则 /api 被信任栅栏拒掉
上游 401 不触发 error_page，proxy_intercept_errors on 是自动换 cookie 的前提
token 每进程轮换、cookie 签名密钥持久化；用 ExecStartPost=+脚本 把 token 同步给 nginx，重启后进入无感
按 RCE 服务对待：独立用户、只读根、只写自己 home、清空 capability，再用 ACL 挡住同机其他家目录
非回环页面的设置页是禁用的，模型与凭据统一走 settings.yaml 和环境变量

把云主机挂成本地盘：WSL + Windows 双端实战

Wed, 16 Sep 2026 22:40:00 +0800

博客和代理跑在同一台 Azure 小机器上，改文件只能 ssh + vim。于是把它的家目录挂成本地盘：WSL 里是普通路径，Windows 里是盘符。

场景	方案
终端 / VS Code	WSL：`~/remote/vm`（sshfs + systemd，断线自愈）
资源管理器	Windows：Z: 盘（rclone + WinFsp）

前提：这台机器直连不通——TCP 握手能通，SSH 立刻被 reset，所有流量必须走本机 clash 代理（127.0.0.1:7890）。

WSL 侧：sshfs + systemd 自愈

sshfs 协议成熟、支持断线重连，用起来和本地路径没差别。先让 SSH 走代理：

Host proxy-vm
 HostName 20.48.50.55
 User azureuser
 IdentityFile ~/.ssh/id_rsa
 ProxyCommand nc -X connect -x 127.0.0.1:7890 %h %p

再交给 systemd user 服务托管，断线自动重挂：

# ~/.config/systemd/user/azure-proxy-vm-mount.service
[Unit]
Description=Mount Azure proxy-vm home via SSHFS
StartLimitIntervalSec=0

[Service]
Type=simple
ExecStartPre=-/usr/bin/fusermount3 -uz %h/remote/vm # 清掉残留挂载
ExecStart=/usr/bin/sshfs proxy-vm:/home/azureuser %h/remote/vm -f \
 -o reconnect,ServerAliveInterval=15,ServerAliveCountMax=3
ExecStop=/usr/bin/fusermount3 -u %h/remote/vm
Restart=always
RestartSec=10

[Install]
WantedBy=default.target

systemctl --user enable --now azure-proxy-vm-mount
sudo loginctl enable-linger $USER # 不登录也保活

实测：kill -9 后 10 秒内自动恢复。

Windows 侧：为什么最后选了 rclone

目标：资源管理器里出现一个盘符。

先试了 SSHFS-Win（WinFsp 上的 sshfs 移植），挂载直接报 read: Connection reset by peer：它不支持 SOCKS 代理，Windows 上也没有 connect / ncat 这类跳板工具，直连又会被 reset。

换成 rclone：自带 SSH 客户端，一行 socks_proxy 就能走 clash，私钥、known_hosts 校验都支持：

# %APPDATA%\rclone\rclone.conf
[azure]
type = sftp
host = 20.48.50.55
user = azureuser
key_file = C:/Users/<用户名>/.ssh/id_rsa
socks_proxy = 127.0.0.1:7890
known_hosts_file = C:/Users/<用户名>/.ssh/known_hosts

rclone mount azure:/home/azureuser Z: --vfs-cache-mode full

盘符出现，Z:\ 也能列目录，但资源管理器里没有。

最大的坑：盘符按登录会话隔离

结论：Windows 的盘符按登录会话隔离。

量一下进程令牌里的 AuthenticationId（登录会话 ID）：

WSL 的 interop 进程也在同一个 Windows 会话里，但令牌属于另一个登录会话——从那儿挂载的 Z:，Explorer 看不见。

（小坑：GetTokenInformation 的 TokenStatistics 类号是 10，不是 12——12 是 TokenSessionId；AuthenticationId 在结构体偏移 8 字节。）

解法：挂载必须从交互会话启动。两个入口：

计划任务：登录时自动跑（隐藏窗口）
azure-vm-remount.cmd：需要手动重挂时双击一下

至此，Z: 可见、可用、可自启。

另一个问题：`\\wsl.localhost` 看不到 FUSE 挂载

WSL 里挂好了，但从 \\wsl.localhost\Ubuntu\... 访问是空的。

原因：这个入口由 WSL 的 9p 文件服务器提供，只导出 ext4 根文件系统与 /mnt/c 这类 drvfs；FUSE 挂载（sshfs / rclone / NFS / CIFS）一概不导出。这是 WSL 的架构限制，没有开关。

所以 Windows 端要自己挂一份，不能借 WSL 的挂载。

日常使用

systemctl --user restart azure-proxy-vm-mount # WSL 挂载卡住时

Z:\ # Windows 直接访问
C:\Users\<用户名>\bin\azure-vm-remount.cmd # 重挂
C:\Users\<用户名>\bin\azure-vm-umount.cmd # 卸载

小结

直连不通就全线走代理：sshfs 用 ProxyCommand，rclone 用 socks_proxy
挂载要有自愈：systemd 的 Restart=always、rclone 的 --vfs-cache-mode
盘符是登录会话级的：务必从交互会话启动挂载，否则 Explorer 看不见
\\wsl.localhost 不导出 FUSE 挂载：Windows 端直接另挂一份

我是怎么搭这个博客的

Wed, 16 Sep 2026 21:10:00 +0800

这台博客跑在一台只有 892MB 内存的 Azure 小机器上，同时兼着代理服务。整套方案的第一原则是：轻。以下只讲思路和取舍，代码只放关键几段。

全貌：写作 → 存储 → 展示

 你在浏览器里写作
 │
 ▼
 ┌─────────────────┐
 │ Sveltia CMS │ 写作后台（/admin/）
 │ 文章 + 图片 │
 └────────┬────────┘
 │ 保存时直接提交
 ▼
 ┌─────────────────┐
 │ GitHub 私有仓库 │ ← 唯一的“真相来源”，也是备份
 └────────┬────────┘
 │ 每 1 分钟自动拉取
 ▼
 ┌─────────────────┐
 │ 小机器 (VM) │ git pull → Hugo 构建 → nginx 托管
 └────────┬────────┘
 │
 ▼
 访客访问博客

一句话：GitHub 是内容的家，小机器只负责渲染和展示。 好处很直接：内容永远有一份私有仓库备份；机器只负责构建，压力小；换设备也能写。

选型

Hugo：单文件二进制，整站构建几十毫秒，内存占用几乎可以忽略——在 1GB 小机器上是决定性优势。对比过 Hexo（依赖多）、WordPress（太重）、Ghost（官方建议 1GB 起步）。

Stack 主题：卡片式、自带暗色模式、搜索、归档、目录，社区里最成熟的 Hugo 主题之一。

Sveltia CMS：最初自己写了个网页后台，能用但很土：图片手动传、预览自己写、格式容易出错。换成 Sveltia 后：富文本 + 实时预览、图片拖拽上传、用表单生成 front matter（不会再因格式写错导致文章不显示）、支持草稿和修订历史。它是纯前端（一个 JS 文件从 CDN 加载），不占服务器内存；支持用 GitHub Token 登录，省掉了自建 OAuth 的麻烦。

为什么不直接用 GitHub Pages？

内容都在 GitHub 了，为什么不直接用 GitHub Pages 托管？ 有三个现实约束：

1. 仓库是私有的，Pages 用不了。 免费账号只能从公开仓库发布 Pages，私有仓库发布需要 Pro/Team 付费计划。想省掉这台机器，就得把整个仓库转公开。

2. github.io 在国内基本不可达。 实测：直连 https://xxxx.github.io/ 超时，而自己的 Azure IP 是通的。GitHub Pages 走 Fastly CDN，国内访问不可靠；换一个「更省事」的方案，结果自己和读者都打不开，没有意义。

3. 那台小机器本来 24 小时开着。 它同时兼着代理服务，博客只是「蹭」在上面：nginx + 构建，平时内存占用不到 20MB，边际成本约等于零。

这个架构也没有绑死：内容全在 Git 里，换机器 git clone + 构建就能恢复。哪天仓库转公开、或者 GitHub 访问不再是问题，迁到 Pages 也就十分钟。

没有域名，怎么上 HTTPS？

没有域名就签不了证书，而写作后台的密码不能明文传输。取巧的办法是 sslip.io——一个公共通配 DNS 服务，把 IP 写进域名就能用：

20.48.50.55.sslip.io → 自动解析到 20.48.50.55

有了它，就能走标准 HTTP 验证，用 certbot 签一张浏览器信任的真证书，并自动续期。代价是依赖 sslip.io 这个第三方服务——对个人博客够用。

核心：GitHub 私有仓库 + 双向同步

写作后台直接往 GitHub 提交，小机器上也可能有本地改动，所以需要双向同步：GitHub → 机器（拉新文章），机器 → GitHub（推本地改动），两个方向处理不好容易冲突。

做法是一个每分钟跑一次的脚本，逻辑四步：

先拉取：git pull --rebase --autostash，把远端新文章合并进来
判断要不要重建：只有「有新提交」或「本地有改动」才构建，避免空转
重新构建：Hugo 生成静态页
再推送：本地有改动就提交并推回 GitHub

两个细节：

加锁：定时任务和手动触发可能撞车，用 flock 保证同一时间只有一个同步在跑
记住上次构建的版本：用标记文件记录上次构建的 commit，精确判断站点是否最新

这正是备份：所有会变化的东西——文章、图片、站点配置——都在 Git 里。换机器 git clone 几分钟复原整站；误删文章 git revert 就能回来；每次改动有完整历史。版本控制本身就是最好的备份。

顺带搭的几件小事

HTTPS 自动续期：certbot 定时器自动检查、自动续
缓存策略：HTML 每次校验（刷新即最新），带哈希指纹的 CSS/JS 长期缓存
安全加固：后台路径随机化、Basic Auth、登录限速、响应头加固

踩过的坑

坑	现象	解法
未来日期	文章发了但不显示	Hugo 默认不构建未来文章，开 `buildFuture`
缺少 front matter	随手记的笔记泄漏到公开页面	Hugo 会把它当页面处理，后加了自动告警
并发推送	git 报 `remote rejected`	同步脚本加 `flock`
中文文件名	后台打不开	校验规则放宽到支持中文

成本

机器是 Azure 最低配（2 vCPU / 892MB），本来就在跑代理，博客算是「蹭」的；域名 0 元（sslip.io）；证书 0 元（Let’s Encrypt）；仓库 0 元（GitHub 私有仓库免费）。平时内存占用不到 20MB。

小结

用静态站点保证「轻」，用 Git 仓库保证「稳」，用成熟的 CMS 保证「好写」，用自动化把三者串起来。

它不是最省事的方案（想省事直接用 Ghost 或 WordPress），但在一台很小的机器上、不花钱、有完整掌控权的前提下，这是我能找到的最好平衡。