dsh-ssh-remote
SSH remote execution plugin set for DeepSeek Harness (DSH): give an agent session an ssh://host[:port]/path working directory, and every capability — filesystem, subprocess, shell, search — executes on the remote host over SSH, with the same budgets, output collection, and session-log trail as local sessions.
中文说明见 [README.zh.md](README.zh.md)。
Configure SSH servers in Settings → SSH (address, port, credentials). Saved servers appear in the workspace picker.
A session whose workspace is an ssh:// directory: every command and file operation runs on the remote machine.
Packages
| Package | Role |
|---|---|
@zhaeng/dsh-ssh | Connection pool (service ctx.ssh). Profiles from DSH_SSH_PROFILES env (JSON) or the browser-side settings page. No profiles ⇒ local-only, nothing remote activates. |
@zhaeng/dsh-fs-ssh | SFTP filesystem backend for the fs seam. |
@zhaeng/dsh-subprocess-ssh | Remote exec backend for the subprocess seam. |
@zhaeng/dsh-fs-routing | The composition layer: one ctx.fs / ctx.subprocess / ctx.shell routed by session cwd — local cwds keep the sandboxed local backends, ssh:// cwds run on the remote host. |
@zhaeng/dsh-client-ui-settings-ssh | Browser-side SSH server settings page. |
plugins/ssh-selftest is a dev-only driver that runs one agent turn against an ssh:// cwd end-to-end.
Requirements
The plugin packages are published under the @zhaenggg npm scope; they depend on official @deepseek-ai/* harness packages (dsh-fs, dsh-subprocess, dsh-shell, dsh-sandbox*, cordis, …), which come from the harness install.
The plugin set builds and tests inside a deepseek-harness pnpm workspace checkout: the packages depend on workspace siblings (dsh-fs, dsh-subprocess, dsh-shell, dsh-sandbox*, …). Full ssh:// cwd support also needs the host-side integration (workspace/session/shell/sandbox seams accepting ssh:// cwds); this repository carries the plugin packages, and the host integration ships with the harness.
Compose
In your profile's cordis.patch.yml (or app composition), replace the single-backend rows with the pool plus the routing layer:
- id: fs-sandbox
disabled: true
- id: subprocess
disabled: true
- id: bash-sandbox
disabled: true
- id: pwsh-sandbox
disabled: true
- insert:
- id: ssh
name: '@zhaeng/dsh-ssh'
- id: fs-routing
name: '@zhaeng/dsh-fs-routing'With no SSH profile configured the composition behaves exactly like the local providers it replaces.
Configure servers
DSH_SSH_PROFILES is a JSON array of profiles:
[
{
"host": "192.0.2.10",
"port": 8322,
"username": "zz",
"password": "…",
"cwd": "/home/zz"
}
]privateKeyPath / privateKey are also accepted. A session cwd of ssh://192.0.2.10:8322/home/zz routes to that host; unknown hosts fail loud (no profile for <host>), never a silent local fallback. The browser settings page writes the same profile store.
Develop
Self-contained workspace — build with one command (dependencies come from npm):
pnpm install --ignore-scripts
pnpm -r --filter './packages/*/*' run build # tsc typecheck + tsdown bundles per packageThe package tests (including the REAL-composition suite) run inside a deepseek-harness checkout, where the full workspace graph and dsh-test-sandbox resolve.
Compatibility
dsh-better-sidebar(VSCode-like sidebar: explorer / editor / terminal) works unchanged over remote workspaces: its panels consume the same routedfs/subprocessseams, so a session whose workspace is anssh://directory browses and edits remote files in the sidebar.
Known limitations
- Remote shell commands have no stdin and no PTY (
spawnTerminalrejects with an explicit error). contains()/fileUrl()are structural stubs at the routing layer.- No host-key verification: profiles trust the network path.
- On a Windows host, the routed local shell wraps only the bash sandbox (remote sessions are unaffected).
- Remote writes do not create parent directories (SFTP semantics).
License
MIT