Introduction¶

The DeepSeek Harness (DSH) Web interface is designed for local use by default. If you want to access it from another computer or phone on the local area network (LAN), or from the internet after configuring router port forwarding, you will typically encounter two issues: whether the transmission is encrypted and whether there is login protection before access.

dsh-gateway is a DSH plugin that adds a layer of “HTTPS encryption + account login” remote access gateway for the DSH Web interface. It installs as a dsh plugin and requires no extra independent reverse proxy, certificate service, or login service deployment. After installation, a Remote Gateway card will appear in the DSH settings page, allowing you to enable, restart, modify listening addresses and ports, and manage login accounts.

What is this¶

The repository path is clarknu/dsh-gateway and the license is MIT.

The things it does can be summarized as:

Provides a self-contained HTTPS + login remote access gateway for the DSH Web interface.
Installs as a dsh plugin, requiring no external programs.
Listens by default on 127.0.0.1:3443 and has no accounts by default.
Once listening address and account are configured, it allows access from LAN devices or internet devices after port mapping.
Supports multi-site whitelisting; a single gateway can serve multiple domains or IPs simultaneously.

Core Capabilities¶

Below are the main capabilities provided by this plugin.

HTTPS Encrypted Transmission
You can use your own certificate if you have a domain; if you have no domain or connect via IP directly, a certificate is automatically generated.
Login Protection
Login is required before access. Account, password, and session validity period are configurable, and login failures are automatically rate-limited. Passwords are not stored in plaintext; it is recommended to save password hashes.
Session Management
Login tokens are valid within their expiration period. If you need to force all logged-in devices to log out, you can execute “Logout all” in the settings page to invalidate all sessions.
Multi-site Whitelist
You can specify the actual domains or IPs to be used via sites[].hosts. The gateway only responds to domains or IPs within the whitelist.
Remote Experience Consistent with Local
Real-time messages and other long-connection features work normally. The reverse proxy uses loopback masquerading mode by default, automatically rewriting the Location header, and supports WebSocket upgrades.
Hot Reload
Configuration changes take effect without a restart. The settings page and the gateway: section in settings.yaml can be configured mutually; both are validated and persisted.
Optional Windows Tray Launcher
tools/dsh-tray/ includes a Windows tray utility used to hide the command-line window and manage DSH instances via the menu.

Installation and Activation¶

First, confirm that the current DSH plugin installation method is available. The following command is used to install the dsh-gateway plugin.

dsh plugin --profile web add dsh-gateway

After execution, restart the web application. After restarting, the gateway listens only on 127.0.0.1:3443 locally by default and has no accounts. This default state is fail-closed: no one can login before accounts are configured.

If you only need local access, you can keep the default state; if you want LAN or internet access, you need to configure the listening address and accounts according to the steps below.

Typical Usage¶

The following example uses “accessing from another machine on the local network”.

Configure the listening address and login account.
You can directly edit $DSH_HOME/settings.yaml or operate in the Remote Gateway card on the DSH settings page.

Configure the gateway: section in settings.yaml:

   gateway:
     listenHost: '0.0.0.0'
     users:
       admin: 'scrypt$...'

The value after admin should be a password hash, not the plaintext password.

Generate a password hash.
Use the script in the repository to generate the hash:

   node scripts/hash-password.mjs 'your password'

After generation, fill the output value into the corresponding account’s value in users.

Access the gateway address in the browser on another device.
Assuming the LAN IP of the machine where DSH is located is 192.168.1.10 and the port uses the default 3443, access:

   https://192.168.1.10:3443

The first access will prompt for a self-signed certificate; after trusting it, you will enter the login page and enter your account and password.

If you need to access from the internet, configure router port mapping.
Forward the external port to the machine’s gateway.port, for example the default 3443. Use the public IP or a domain resolved to the machine when accessing. When using a domain, you should configure your own certificate.

Configuration Highlights¶

All configurations can be written in the gateway: section of $DSH_HOME/settings.yaml. The following configuration shows the main fields:

gateway:
  enabled: true
  listenHost: '127.0.0.1'
  port: 3443
  upstream: ''
  sessionDays: 30
  loginFailLimit: 5
  lockoutSeconds: 60
  users:
    admin: 'scrypt$...'
  sites:
    - hosts: ['your domain', 'your IP']
      cert: 'certificate path'
      key: 'key path'

The meaning of each field is as follows:

enabled: Set to false to completely disable the gateway.
listenHost: 127.0.0.1 means only locally reachable; 0.0.0.0 means listening on all network interfaces, allowing LAN access.
port: The external port, default is 3443.
upstream: Leave empty to automatically follow the DSH web service port.
sessionDays: Session validity period, in days, default is 30 days.
loginFailLimit: Maximum number of consecutive login failures per IP.
lockoutSeconds: The number of seconds to lock after exceeding the failure limit.
users: Login accounts; it is recommended to use password hashes for values.
sites: Site whitelist, only responds to domains or IPs listed here.
sites[].hosts: Supports wildcard syntax like *.example.com.
cert / key: Certificate and key paths; if left empty, a certificate is automatically generated.

Note: sites[].hosts should only list the actual domains or IPs used. Do not add uncertain addresses to the whitelist.

Settings Page Card¶

After installation, a Remote Gateway card will appear on the DSH settings page. You can complete the following operations in the card:

View runtime status, such as running, disabled, error, restarting.
Enable or disable the gateway.
One-click restart.
Modify bound IP and port.
Add, modify, and delete login accounts.
Execute “Logout all” to force all logged-in devices to log out immediately.
View recent logs.

Passwords saved in the settings page are automatically hashed; you do not need to manually execute the password hash generation command. Certificate, multi-site, and login rate limiting configurations are still maintained in the gateway: section of settings.yaml.

Security Baseline¶

The following are a few key items to confirm before use.

Do not keep example credentials
Do not keep example credentials like admin / change-me in the configuration. As long as this credential is still effective, the gateway will refuse to start if listening on a non-local address.
Do not store passwords in plaintext
When writing configurations by hand, use password hashes:

   node scripts/hash-password.mjs 'your password'

When saving passwords in the settings page, the system will automatically hash them.

It is recommended that the main DSH binds to the local loopback address
This ensures all remote access goes through the login protection of dsh-gateway. You can lock the webserver to 127.0.0.1 in the web profile’s cordis.patch.yml:

   - id: webserver
     config:
       host: '127.0.0.1'
       port: 3080

The site whitelist should only list real domains or IPs
sites[].hosts is the domain/IP whitelist for which the gateway responds; the smaller the scope, the better.
Distinguish the relationship between sessions and password changes
Login tokens remain valid until expiration, with a default validity period of 30 days. Changing the password will not automatically log out already logged-in devices. If you want all clients to log in again, you need to execute “Logout all”. If you want to revoke a single user, simply delete the corresponding account.
Internet access depends on router port mapping
The router must forward the external port to the machine’s gateway.port. If using a domain, the domain must be resolved to the machine, and a certificate must be configured.

Reverse Proxy Behavior¶

The gateway forwards requests by default in loopback masquerading mode. The upstream service sees 127.0.0.1:<upstreamPort> as the Host/Origin, not the client’s real domain.

This brings several practical effects:

DSH’s API trust fence can be bypassed without extra startup arguments, including privileged APIs like credentials and settings.
There is no need to pass --trusted-host to dsh web anymore.
Absolute Location headers returned by the upstream will be automatically rewritten back to the client’s public address, for example https://<clientHost>/....
WebSocket upgrades follow the same forwarding logic and do not require extra configuration.
Cross-site requests with sec-fetch-site: cross-site will still be rejected by the upstream, and CSRF protection remains unaffected.

Development and Runtime Requirements¶

Node version requirement is declared as >=22.0.0 in package.json, and the license is MIT.

During development, you can execute the following commands in the repository directory:

npm install
npm test

The main directories in the repository are as follows:

lib/: Core logic, including authentication, proxying, certificates, HTTPS server. It is independent of the plugin framework and can be tested independently.
dsh/index.js: Plugin wrapper, including configuration parsing, lifecycle, hot reload, and security guards.
client.js: Settings page card, runs in the browser.
scripts/: Supporting scripts, such as hash-password.mjs used to generate password hashes.
tools/dsh-tray/: Optional Windows tray launcher.

Applicable Scenarios and Notes¶

dsh-gateway is suitable for the following scenarios:

Wanting to access the DSH Web interface on computers, phones, and tablets within the local network.
Wanting to access the DSH Web interface from the internet via router port mapping.
Wanting remote access that simultaneously features HTTPS, login protection, session invalidation, and multi-site whitelisting.
Not wanting to deploy an extra reverse proxy, certificate management, and login system.

Before use, you need to confirm:

When the local machine and the access device are on the same network, listenHost needs to be set to 0.0.0.0, and the port is not blocked by the firewall.
When accessing from the internet, the router must complete port mapping.
When using a domain, the domain needs to be resolved to the machine, and a certificate needs to be configured.
After loading as a DSH plugin, it runs with the current dsh process; you should check the source code, license, and configuration items before installing.

Conclusion¶

The value of dsh-gateway lies in encapsulating “remote access to the DSH Web interface” into a plugin: after installation, it provides HTTPS, login protection, session management, multi-site whitelisting, and an entry point for settings page operations. Listening only locally without configured accounts is a fail-closed security starting point; after configuration, both LAN and internet access can use the same set of login and certificate policies.

dsh-gateway: Remote access gateway providing HTTPS and login for the DSH Web Interface.