自建服务 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 和环境变量

白嫖 Azure 学生订阅：$100 额度 + 一台常驻 VPS

Wed, 16 Sep 2026 23:30:00 +0800

这个博客和代理服务跑在一台 Azure 学生订阅的小机器上：日本东部、2 vCPU / 892MB，由 $100 学生额度覆盖。以下是从认证到能用的全过程，数据来自这台机器的实测。

一、入口：学生认证

Azure for Students：用学校邮箱完成学籍认证，就能拿到 $100 额度 / 年，在读期间每年可续，不需要信用卡。额度可以花在虚拟机、磁盘、流量等几乎所有资源上。

几点经验：

edu 邮箱认证最快；没有的话按页面提示走其他学籍验证
免费服务清单里还有一批「12 个月免费」和「永久免费」的小资源，轻量用途基本够
认证通过后先别急着点创建——下一步更重要

二、先查区域：学生订阅有白名单

注意：能列出的区域 ≠ 你能创建的区域。学生订阅常有区域限制，创建时报 RequestDisallowedByAzure，就是被策略拦了。

# 列出推荐区域
az account list-locations \
 --query "[?metadata.regionCategory=='Recommended'].{name:name, display:displayName}" -o table

# 查区域策略限制
az policy assignment list \
 --query "[?contains(properties.displayName,'ocation')].{name:name, display:properties.displayName}" -o table

选区域的思路：

目的	区域
国内低延迟	`japaneast` / `koreacentral` / `southeastasia`
美区解锁	`westus2` / `westus3`

这台机器在 japaneast：实测国内直连 443 正常，22 端口会被干扰（TCP 握手能过，SSH 随即被 reset）——这也是本站 SSH 走代理连接的原因。

三、开机器：B 系列突发型

个人用途首选 B 系列突发型：便宜、平时攒 CPU 积分、闲时省额度。这台用的是：

VM_SIZE = Standard_B2ats_v2 # 2 vCPU / 1 GiB，约 $8/月
IMAGE = ubuntu-24_04-lts

创建时的三个要点：

SSH 公钥 + 禁用密码登录（disablePasswordAuthentication=true）
NSG 只开必要端口：22（建议限制来源）、80 / 443，代理端口按需
系统盘标准 SSD 就够：61G 实测只用了 4.6G

四、开机后三件事

1. 加 swap（小内存必做）

892MB 内存跑 nginx + Hugo 构建 + 代理，不加 swap 迟早 OOM：

sudo fallocate -l 2G /swapfile && sudo chmod 600 /swapfile
sudo mkswap /swapfile && sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

2. 开 BBR

跨境线路建议开 BBR：

echo 'net.core.default_qdisc=fq' | sudo tee -a /etc/sysctl.d/99-bbr.conf
echo 'net.ipv4.tcp_congestion_control=bbr' | sudo tee -a /etc/sysctl.d/99-bbr.conf
sudo sysctl --system
sysctl net.ipv4.tcp_congestion_control # 应输出 bbr

3. 防火墙：NSG 和系统防火墙只管一层

Azure 的 NSG 在云侧挡流量，系统里还有一层（ufw / iptables）。两层要么都配好、要么明确交给一层。常见问题：NSG 放行了 443，机器里 ufw 却拦着。

这台机器实测 ufw 是 inactive，访问控制统一交给 NSG。

五、成本账：$100 能跑多久

B2ats_v2 约 $8/月 → $100 差不多正好一年
只在需要时开机能更久，但注意：「停止」≠ 停止计费，要在门户里选「停止(释放) / deallocate」
公网 IP、磁盘、流量都是单独计费项，删机器时别忘了一起清理

六、踩坑清单

坑	现象	解法
区域白名单	建 VM 报 `RequestDisallowedByAzure`	换区域，或先跑第二步的查询
Cloud Shell 没建存储	每次重开连不上 VM	首次使用时按提示创建存储账户
NSG 与系统防火墙不一致	端口「明明开了」却不通	两层都查，或统一交给 NSG
国内直连 22 端口	SSH 被 reset（TCP 握手却成功）	走代理连，或换高位端口观察
B 系列 CPU 积分	跑重活突然变慢	它是突发型，别当计算型用
892MB 内存	构建时 OOM	加 swap（见上）

七、这台机器的现状（实测）

它同时跑三件事：sing-box 代理、这个博客（nginx）、Filebrowser 文件管理。日常内存 ~500MB，swap 仅 88MB，不跑重活完全够用。

参考：linux.do《学生版 Azure 部署教程（含踩坑与解决方法）》，区域白名单和 NSG 的坑记录得更细。

小结

学生认证是最划算的入口：$100/年、免信用卡，够一台小机器跑一整年
动手前先查区域白名单：能列出来 ≠ 能创建
B 系列突发型 + swap + BBR 是小机器的标准三件套
NSG 和系统防火墙只管一层，并记住是哪一层
不用时记得 deallocate，否则额度会静默消耗

我是怎么搭这个博客的

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），但在一台很小的机器上、不花钱、有完整掌控权的前提下，这是我能找到的最好平衡。