dsh-remote-access

One-command setup for password-protected remote access to the DeepSeek Harness (dsh) web UI — the same production setup used by the author on their own tailnet.

dsh web binds to 127.0.0.1 only, and a hardcoded set of privileged methods (settings.*, credentials.*, agentPreset.*, llm.discoverModels, …) is loopback-only by design ("until a real authentication layer exists"). This project makes remote full-featured access practical today:

browser → TLS (Tailscale Serve / reverse proxy) → Caddy (password auth) → dsh (loopback)

What the script does

1. Patches the dsh privileged-methods fence (one line) so trusted hosts are allowed instead of loopback-only. Idempotent, keeps a .bak backup.
2. Installs the official Caddy (apt or direct binary download; GH_PROXY mirror variable supported for CN networks) and writes a Caddyfile with bcrypt basic auth that reverse-proxies to the loopback dsh server.
3. Installs a systemd user service for the auth proxy (auto-start, crash-restart, journald logs).
4. Prints the Tailscale Serve command and access URL.

Quickstart

git clone https://github.com/wuwuzhige-sudo/dsh-remote-access
cd dsh-remote-access

./scripts/setup-remote-access.sh \
  --password 'choose-a-strong-password' \
  --user dsh \
  --trusted-host myhost.tailXXXX.ts.net     # your Tailscale DNS name

# then:
sudo tailscale serve --bg 3081
systemctl --user restart dsh-web

Open https://<machine-name>.<tailnet>.ts.net — a password prompt appears, and the full dsh UI (settings, agent presets, credentials, model discovery included) works remotely.

If dsh web runs through a reverse proxy / Tailscale Serve, the browser origin is a real hostname, so the dsh server must be started with dsh web --trusted-host <hostname> (and the same value passed to the script via --trusted-host).

Options

Why not a plugin?

Two of the three moving parts cannot live inside the dsh plugin system:

• Caddy is a separate process (a reverse proxy) — dsh plugins only run inside the dsh process.
• The privileged-methods fence is hardcoded in dsh-client-connection (a module-private closure); a plugin cannot bypass it from the outside, and the webserver route registry does not allow intercepting /api ahead of the built-in route.

The --trusted-host flag itself is official dsh functionality. This script simply assembles the pieces.

Security

⚠️ The dsh web UI can execute arbitrary commands on the host. Anyone with the password can drive it.

• The dsh server must stay bound to loopback — the Caddy proxy is the only public entry.
• The password is stored as a bcrypt hash only (in ~/.local/share/dsh-remote-access/Caddyfile).
• Use a strong, unique password. Over Tailscale the traffic is encrypted end-to-end and constrained to your tailnet.
• This is a stopgap: the dsh project plans a real authentication layer. When it ships, drop the patch + proxy and use the official auth.

Uninstall

systemctl --user disable --now dsh-caddy
sudo tailscale serve --https 443 off
rm -f ~/.config/systemd/user/dsh-caddy.service ~/.local/share/dsh-remote-access/Caddyfile
# restore the dsh patch (see the .bak path printed during setup)
mv <dsh-client-connection>/lib/index.js.bak <dsh-client-connection>/lib/index.js

License

MIT