能不能支持ssh远程连接项目

[pkgunboat]

希望可以支持ssh远程连接，让agent本地操作服务器上的文件

[bobleer]

这个需求真要做，建议别只加一个“ssh 执行命令”工具。那样 terminal 在服务器，文件读取、搜索、Skill 发现、Agent 子进程还可能偷偷落回本机，跑真实项目很容易一半远程一半本地。

更稳的边界是把 workspace 本身变成一个 target：选中 SSH 后，文件树、read/write、terminal、grep/index、Agent subprocess 都从同一套 FS/stdio port 走，远端路径始终按 POSIX 解释。这样 tool 层不用每个都认识 SSH，只依赖 workspace capability。

利益相关，我参与 BitFun。我们已经按这条路做了 Remote Workspace：直连 SSH、ProxyJump 链、SSH 主机里的 Docker、本地 Docker 都能作为同一个 workspace target；SFTP、terminal、Agent、ACP、搜索都会留在目标端，不会静默回退本机。实现和边界写在 docs/features/remote-workspaces.md / docs/architecture/remote-workspace-transport.md，源码也开着：https://github.com/GCWing/BitFun

DSH 现在本身已经有 ctx.fs / session / tool registry 这些 seam，我感觉把 remote workspace 做成 provider 会比给每个 tool 打补丁更顺。

[Yan-Zero]

我也需要这个功能，所以写了个第三方插件 dsh-remote-ssh：https://github.com/Yan-Zero/dsh-remote-ssh

它的思路是把远端 SSH 主机直接作为透明工作区。在设置里配好主机后，读写文件、跑 bash 甚至搜索（远端 rg）都在服务器上执行，不需要改动 agent 的工具习惯

欢迎试用，有什么问题或建议随时提 issue

[liyangbing]

SSH 远程项目如果进入 DSH，建议把它建模为显式的 remote Workspace/provider，而不是让本地 Agent 透明继承服务器上的全部权限。

可以先定义一份最小能力合同：

• Workspace 固定 host、port、user、remote root 和 connection identity；首次连接校验并持久化 host key 指纹，变化时 fail closed，不自动接受新 key。
• 认证材料由 host/credential helper 管理，不能进入 prompt、Session 日志或插件配置；密码、token、私钥和 agent socket 路径都只做引用，不做明文复制。
• 将远程能力拆开声明：列目录/读文件、写文件、执行命令、端口转发、安装依赖；默认只读，写入和执行分别经过 approval/sandbox，不能因为 SSH 成功就授予全部能力。
• 所有命令记录 remote Workspace identity、shell、cwd、argv/退出码和超时状态；不要仅记录本地 cwd，也不要把服务器完整路径或环境变量写入公开日志。
• 连接断开、host key 变化、权限拒绝和部分写入都要有明确失败分支；文件写入采用临时文件 + 原子替换或可恢复事务，取消后不能留下半成品。
• 验收覆盖本地/远程 Workspace 切换、并发 Session、断线重连、非 ASCII 路径、跳板机/端口转发和最小权限矩阵，并证明本地工具不会误写远程目标。

独立社区 handbook 的远程运行与安全边界参考： https://github.com/sandbaseai/deepseek-harness-handbook/blob/main/docs/en/integrations/acp-remote-hosting.md

本 handbook 是独立社区项目，并非 DeepSeek AI 官方项目。