A 9-point comparison of 7 remote access approaches for DSH

[yangbobo2021]

DeepSeek Harness 0.1.2-alpha added a browser launch-token and signed-cookie flow. That raises the bar for remote access: making port 3080 reachable no longer proves that Host RPC, WebSocket streams, and browser sessions work correctly.

We reviewed seven approaches against one acceptance set designed for a regular user running DSH on another computer or a headless Linux server:

1. no manual SSH, VPN, NAT, proxy, domain, or certificate configuration;
2. headless Linux support;
3. access from a normal desktop or mobile browser;
4. the complete native DSH Web UI;
5. no public inbound port on the host;
6. end-to-end confidentiality from the relay;
7. preservation of DSH's own token/cookie authentication;
8. explicit 0.1.2-alpha compatibility evidence;
9. managed certificates, reconnects, device revocation, launch URLs, and version changes.

Result summary

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

Why the KeySync path is different

KeySync separates three trust boundaries:

• A short-lived, single-use, user-and-device-scoped grant decides who may reach the device.
• The remote browser's TLS connection passes through Relay and terminates at the device Gateway. The certificate private key stays on the device, so Relay cannot decrypt DSH content.
• The device Gateway completes DSH's own launch-token exchange and preserves the DSH cookie for HTTP and WebSocket traffic. The KeySync session cookie is stripped before upstream forwarding.

This is relay-assisted end-to-end TLS, not direct network P2P. The design favors predictable reachability across NAT and firewall conditions while retaining the important privacy property: plaintext exists only in the browser and on the user's device.

The current KeySync release acceptance matrix covers TLS passthrough, SNI routing, replay rejection, cross-user isolation, slow-stream isolation, reconnection, same-device route takeover, the alpha.2 launch-token bootstrap, cookie preservation, WebSocket traffic, and attachments.

For direct-P2P-first or dedicated Android workflows, ds-harness-remote and the mobile-oriented projects deserve serious evaluation. For a non-network-specialist who wants the complete DSH interface in any browser, KeySync is the only approach in this comparison that passes all nine target criteria together.

Read and try

• Full comparison preview
• Download KeySync
• DSH browser authentication documentation
• Codex DSH plugin / npm
• Claude Code DSH plugin / npm

The Codex and Claude Code packages are conversation-backend plugins. They are optional and separate from KeySync's remote transport.

Feedback is welcome on the acceptance set itself, especially criteria that matter in real remote DSH deployments but are missing here.