DeepSeek Harness remote access: SSH, proxy and bridge

dsh ssh is not a command; it is a family of remote access methods: SSH tunnel, reverse proxy, and bridge plugin. All three open the Web UI from another machine; setup cost and security boundaries differ.

Correct the name first

Typing dsh ssh returns not found. It is not a built-in subcommand but community shorthand for "access a remote dsh over SSH" (source).

The real steps are two: start the web service on the server, then use SSH or a proxy to map the port safely.

Understanding this prevents hunting for nonexistent flags. The problem is "how to carry the local port to the remote machine," not a specific dsh subcommand.

Three methods

Each has its own scenario; you do not need all three.

The tunnel is cheapest: no domain, no certificate, one command. Its weakness is that closing the session removes the tunnel. The reverse proxy is the most stable: centralized TLS, authentication, and source limits, at the cost of gateway maintenance. A bridge plugin wraps the flow into a plugin, reducing steps, but the network still needs authentication and exposure control.

SSH tunnel: temporary access

Best for temporary troubleshooting and single-user access.

1. Start the web service on the server, listening on 127.0.0.1 and a port.
2. On the local terminal run ssh -L local-port:127.0.0.1:remote-port user@server.
3. Open http://127.0.0.1:local-port locally.
4. Keep the SSH session open; reconnect when it drops.
5. For longer use, enable auto-reconnect or move to a reverse proxy.

The tunnel maps a port; it does not widen the listen address. Keeping the service on localhost is safer; do not change it to all interfaces for convenience.

A dropped tunnel is normal. Check the SSH session before restarting the service.

Reverse proxy: long-term access

For long-term or multi-user access, a reverse proxy is the better fit.

1. Configure a domain and TLS certificate on the gateway, pointing to the local service.
2. Add at least one authentication layer.
3. Configure source limits to reduce scanning.
4. Test from an external network.
5. Keep access logs and review unusual sources.

TLS and authentication are two bottom lines; reverse proxy errors are also harder to diagnose. A missing layer makes public access unsafe. When you see 502, CORS errors, or a login loop, check forwarding and headers before the service itself.

Bridge plugins

Plugins suit people who do not want to hand-write configuration, but check the source first.

1. Confirm owner, source, and update time in the Hub.
2. Read which ports and permissions the plugin opens.
3. Configure an account or token; do not reuse the main password.
4. Test in a controlled network and confirm the access scope.
5. Disable or uninstall when unused to reduce exposure.

A plugin is not a security boundary. If it requires exposing the service publicly, the risk remains; unknown sources should not be used at all, since they may request high permissions or forward traffic.

Comparison

Choose by duration, number of users, and whether you can maintain a gateway.

Separate temporary from long-term. Using a tunnel for daily work causes repeated disconnects; using a proxy for a one-off is overkill.

The methods can combine. A public proxy plus a tunnel for emergencies; keep authentication consistent.

Connection and authentication troubleshooting

Remote problems fall into "cannot connect" and "cannot get in."

1. Cannot connect: is the tunnel or proxy alive, is the service listening, is the port reachable?
2. Cannot get in: login page, expired token, or source restriction?
3. Blank page: is the proxy forwarding static assets and headers correctly?
4. Frequent drops: SSH session, proxy timeout, or network switching; mobile networks drop most often.
5. Partial features fail: WebSocket or long connections interrupted by the proxy.

Separate the two layers before changing configuration. Keep proxy logs, service logs, and SSH records; comparing all three locates the layer quickly.

Security bottom lines

Four rules apply to every method.

1. Do not expose the port directly, and do not listen on all interfaces unless required; public access needs TLS and authentication, while localhost plus a tunnel or proxy is safer.
2. Do not forward tokens. Treat tokenized links as temporary keys and rotate after use.
3. Limit sources. Restrict by IP or subnet when possible.
4. Review logs. Long-running entries need someone watching unusual access.

These are prerequisites, not suggestions. Remote access exposes the workspace to another network; relaxing any rule increases risk.

Next steps

Decide temporary or long-term, then choose. For the reasoning and prerequisites, read How to connect with dsh ssh. For mobile access, read DeepSeek Harness on mobile. For reverse proxy details, read DeepSeek Harness reverse proxy.

Sources: DeepSeek Harness docs, dsh CLI README, deepseek-harness repository