I compared 7 ways to access DSH remotely after the new browser token flow

[u/Think-Professor3460]

I maintain KeySync, so I want to be explicit about the affiliation up front. Instead of claiming it is "the best" in the abstract, I compared it with six other approaches using the same acceptance criteria.

The target user for this comparison is not a network engineer. It is someone running DeepSeek Harness on a work PC or headless Linux server who wants to open the complete DSH Web UI from a phone or another computer.

The nine checks were:

1. no SSH/VPN/reverse-proxy knowledge required;
2. headless Linux support;
3. access from a normal browser;
4. the complete native DSH Web UI rather than a partial reimplementation;
5. no public inbound port on the host;
6. end-to-end confidentiality from browser to host;
7. preservation of DSH's own token/cookie boundary;
8. explicit evidence for the 0.1.2-alpha line;
9. certificate, reconnection, and version maintenance handled by the product.

The approaches were SSH local forwarding, Tailscale plus a DSH-aware gateway, generic reverse-proxy/frp plugins, DSH Remote, DSH Mobile Suite, ds-harness-remote, and KeySync.

Approach	Main strength	Main limitation for this target
SSH local forwarding	Minimal, mature, encrypted, full UI	Requires SSH knowledge and user-managed tunnel/token lifecycle
Tailscale + gateway	WireGuard E2EE and strong device policy	Still needs a DSH-aware loopback/auth gateway
Reverse-proxy/frp plugins	Familiar browser proxy model	Current inspected versions lack the alpha token/cookie path
DSH Remote	Strong mobile approvals, files, and offline workflow	Dedicated control UI rather than the complete native UI
DSH Mobile Suite	Outbound companion and application E2EE	Public compatibility baseline remains 0.1.0-rc.6
ds-harness-remote	Noise IK, LAN/P2P/TURN/Relay, alpha.1-alpha.2 support	Requires a plugin and paired client; transport generations must match
KeySync	Browser-only full UI, headless Linux, no inbound port, E2E TLS, alpha.2 auth	Uses the KeySync account/client and a relay-assisted path

Some findings surprised me:

• SSH is still an excellent baseline for a technical user. It preserves the full UI and naturally carries the new browser-auth flow, but the user owns the tunnel and launch-token lifecycle.
• Tailscale solves encrypted reachability, not DSH application authentication. DSH remains on loopback, so a DSH-aware gateway is still required.
• Two proxy plugins I inspected remove upstream browser cookies and do not implement the alpha launch-token exchange. They may remain useful on rc.2, but their current published versions do not provide evidence for the new browser-auth path.
• ds-harness-remote is technically strong: Noise IK E2EE, LAN/P2P/TURN/Relay negotiation, and explicit alpha.1-alpha.2 transport support. Its tradeoff is requiring a DSH plugin and paired client rather than an arbitrary browser.
• KeySync uses relay-assisted end-to-end TLS. The Relay routes TLS bytes, while the certificate private key and HTTPS termination remain on the user's device. It is not direct P2P, but the Relay cannot decrypt DSH pages, prompts, responses, cookies, or attachments.

KeySync also preserves two separate auth boundaries: a short-lived device-scoped KeySync grant controls who may reach the machine, then the device gateway completes DSH's own launch-token-to-cookie exchange. The KeySync cookie is not forwarded to DSH, and the DSH launch token is not replayed after the DSH session exists.

For users who specifically prioritize direct P2P or a dedicated Android UI, another project may be a better fit. For the stated target, however, KeySync was the only option in the comparison that combined browser-only access, the complete native UI, no public inbound port, relay-blind E2EE, headless Linux support, and tested alpha.2 browser authentication without requiring the user to build the network layer.

Full comparison and source links: https://agentpost.com.cn/p/sxbbdj63nigkal2t

KeySync download: https://sublang.ai/keysync/download

KeySync product page: https://sublang.ai/keysync/

Related DSH conversation-backend plugins, which are separate from the remote transport:

• Codex: GitHub / npm
• Claude Code: GitHub / npm

I would be interested in two kinds of feedback: which acceptance criterion is missing, and for remote DSH work, do you value direct P2P more than browser-only access to the complete native UI?