seek://map/dsh-hardssh
dsh-hardssh — SSH Workspaces and SSH Ops for DSH
#ssh #workspace #remote #terminal #web-ui
TL;DR
Per its README, dsh-hardssh turns a server directory into an SSH workspace whose sessions run file I/O and commands transparently on the remote host; plugins on the standard ctx.fs / ctx.subprocess interfaces run remotely with zero changes. Session-bound SSH operations, host management and a secure-by-default credential policy ship alongside. Maintained by tiphareth0; published on npm.
dsh-hardssh binds a directory on any SSH server as a DSH workspace: once a session is bound, its file I/O and command execution run transparently on the remote host, and plugins working through the standard `ctx.fs` / `ctx.subprocess` interfaces follow along with zero changes — the plugin replaces DSH's service seams via `cordis.patch.yml` rather than modifying the core. The right-sidebar console follows the current session's server (web terminal, SFTP transfers, tunnels, remote commands), and credentials stay off disk by default with an opt-in encrypted vault. It is unrelated to the dsh-web entry's SSH/SFTP ops panel — a separate project by a different author, whose emphasis is workspace-level transparent routing.
Facts
- install
- dsh plugin --profile web add @tiphareth/dsh-hardssh
- license
- BSD-3-Clause
- note
- 仓库 README 记 0.2.2；本站 2026-09-13 探测 npm registry，latest 已读到 0.2.3。
Key points
- Per its README, once an SSH workspace is bound, file I/O and command execution in that session run transparently on the remote host; the mechanism is a cordis.patch.yml that disables the deployment's built-in fs-sandbox / subprocess rows and mounts this plugin's routing facades, so any plugin working through the standard ctx.fs / ctx.subprocess interfaces runs remotely with no SSH code of its own
- The README states the exception plainly: glob / grep run the client's bundled ripgrep and cannot read the remote workspace, so those calls are refused inside an SSH session (never silently answered no-matches) and pointed at remote_search or ssh_exec; pwsh / powershell / cmd are client-native binaries running on the local machine, while read / write / edit / bash go through the replaced seams and take effect on the server
- Per its README, SSH operations follow the session: web terminal (xterm + WebSocket PTY), SFTP upload/download, local port forwarding, and remote commands on the current server; the console has no host dropdown — its target is forced to the current session's SSH workspace so a panel action can never hit the wrong machine
- Agent tools include ssh_list / ssh_exec / ssh_upload / ssh_download / ssh_tunnel / ssh_cluster plus the remote workspace tools remote_status / remote_ls / remote_search, with cross-host fan-out via ssh_cluster; the host panel lists hosts and workspaces grouped per server, with CRUD and ~/.ssh/config import
- Secure defaults: passwords / passphrases are never persisted by default (secretStorage: none, entered once and reused for the connection's lifetime); an opt-in vault mode (AES-256-GCM + scrypt) serves unattended agents; host keys use TOFU first-trust with immediate warning on change; remote paths are strictly confined and symlink escapes fail closed
- Per its README, the workspace base is platform-neutral: SSH is just one provider beside local, and the same base can host docker / wsl / cloud devboxes with no changes to the plugins, tools or UI above it; the rare plugin carrying its own file/process abstraction swaps a few touch-points, with an agent-ready manual at packages/dsh-hardssh/SKILLS.md
- No core modification — shipped as a normal plugin (directory flow, left-sidebar global entry row, right-sidebar tab); per its README it is compatible with DSH 0.1.5 (tested against 0.1.5-rc.1); the npm package @tiphareth/dsh-hardssh is published — this site's registry check on 2026-09-13 read latest as 0.2.3 (the repo README says 0.2.2)
FAQ
Do existing DSH plugins need code changes to run on a server?
Per its README, most plugins need zero changes: anything working through the standard ctx.fs / ctx.subprocess interfaces runs on the remote host inside an SSH-workspace session automatically. The rare plugin with its own file/process abstraction or local/remote state swaps a few touch-points for generic-base equivalents (the README carries an interface mapping table), and packages/dsh-hardssh/SKILLS.md is an execution manual written for agents — detection commands, the mapping table, copy-ready snippets and a self-check list.
Do glob / grep work inside an SSH session?
Per its README, no — and they never fail silently: both run the client's bundled ripgrep, which cannot read the remote workspace, so the plugin refuses those calls inside an SSH session and points at remote_search (mode=glob or mode=grep) or ssh_exec. Likewise pwsh / powershell / cmd are client-native binaries and run locally; remote file I/O and command execution (read / write / edit / bash) go through the replaced seams and take effect on the server.
Are passwords written to disk?
Per its README, nowhere by default (secretStorage: none, VSCode Remote-SSH style): entered once per connection lifetime, asked again after an idle pool recycle. For unattended access to password hosts, vault mode stores credentials encrypted (AES-256-GCM + scrypt) as an explicit opt-in, with auto-unlock off by default unless vaultAutoUnlock enables it; host keys use first-trust TOFU with an immediate warning on change.
How does this relate to the SSH/SFTP ops panel in this map's dsh-web entry?
They are separate projects by different authors: the dsh-ssh panel belongs to zhu1090093659's Web UI bundle, while dsh-hardssh is maintained by tiphareth0 and its README does not mention dsh-web. The emphasis differs — the bundle ships an SSH/SFTP ops panel, whereas dsh-hardssh's distinctive capability is binding a remote directory as an SSH workspace so the whole session's files and commands route transparently through the seams.
Official references