在 DeepSeek Harness 中通过 SSH 使用远程服务器：dsh-remote-ssh 配置与排障指南#

如果你平时在本地使用 DeepSeek Harness，但代码、数据、Conda 环境甚至 GPU 都在远程服务器上，那么一个很自然的需求就是：

能不能让 DSH 本身继续运行在我的电脑上，但让它像操作本地项目一样操作 SSH 服务器上的项目？

dsh-remote-ssh 就是为这个场景设计的。 它和“把整个 DeepSeek Harness 安装到服务器上”并不是一回事。更有意思的是，它也不是简单地把远程目录同步一份到本机。 它可以让：

1
本地 Mac
2
│
3
├── DeepSeek Harness
4
├── 模型配置
5
├── API Provider
6
├── Session
7
├── Plugins
8
└── Skills
9
      │
10
      │ SSH + AHP
11
      ▼
12
远程 Linux Server
13
│
14
├── 项目源码
15
├── 数据集
16
├── Conda / Python 环境
17
├── Bash
18
├── GPU
19
└── 真实文件系统

也就是说： Agent 留在本机，执行环境留在服务器。

2. dsh-remote-ssh 到底做了什么？#

这个插件最重要的设计理念其实不是“SSH”，而是：

把远程目录变成 DSH 的一个透明 Workspace。

例如本地项目可能显示为：LOCAL > my-project 远程项目则显示成：Server > aigc_detector 当你进入本地 Workspace 时：

1
read
2
write
3
grep
4
glob
5
bash
6
background task

这些工具全部操作本机。

进入远程 Workspace 时，同样这些工具则被透明地路由到服务器。 也就是说，模型看到的仍然是：

1
read
2
grep
3
bash

而不是另一套：

1
remote_read
2
remote_grep
3
remote_bash

这是我比较喜欢这个插件的地方。 上游设计明确要求：当 Workspace 是远程的时，文件系统、搜索、Shell 和后台任务都在对应 SSH 主机执行；如果远程环境失败，也不会偷偷 fallback 到本机。

3. 它不是“同步工具”#

这一点特别重要。 假设服务器项目是：

1
/home/user/projects/aigc_detector

把它加入 DSH 后，并不意味着：

1
Server
2
    ↓ rsync
3
Mac
4
    ↓
5
本地复制一整份项目

真实情况更接近：

1
DSH Workspace
2
    │
3
    ├─ 身份：Server > aigc_detector
4
    │
5
    └─ 实际文件仍然位于
6
          ↓
7
/home/user/projects/aigc_detector

因此服务器上一个几十 GB 的项目，不会因为你把它加入 DSH 就自动下载几十 GB 到本机。 这也让本地和服务器之间保持了非常清晰的边界。

4. Remote Workspace 和 Backend 是两回事#

这是使用这个插件时最容易混淆的地方。

1
Mac
2
│
3
├── DSH
4
├── Agent
5
├── Session
6
├── Model / API
7
├── Plugins
8
├── Skills
9
│
10
└──── SSH + AHP ────► Server
11
                      │
12
                      ├── Files
13
                      ├── Bash
14
                      ├── Search
15
                      ├── Python
16
                      ├── Conda
17
                      └── GPU

1
在 Web 中打开 Backend

1
Mac Browser
2
      │
3
      │ SSH tunnel
4
      ▼
5
Remote Server
6
│
7
├── dsh-host
8
├── Agent
9
├── Session
10
├── Tools
11
├── Workspace
12
└── Harness Backend

1
~/.dsh-host

5. 权限模型：DSH 到底能访问服务器什么？#

这里也需要特别注意。 Remote SSH 并不是一个操作系统级 Sandbox。 它最终拿到的权限，就是：

1
你 SSH 登录这个服务器账号所拥有的权限

例如你通过：

1
User zx

登录，那么 DSH 的远程工具本质上也运行在：

1
zx

这个 Unix 用户身份下。 插件当前为了保持本地与远程工具行为一致，采用的是偏向完整访问的策略；README 也明确指出，AHP permission 本身不是 OS sandbox，如果 DSH 策略允许 Full Access，那么同一个 SSH 用户能访问 Workspace 外该 Unix 用户本身有权访问的路径。 所以：

1
DSH 权限
2
    ≤
3
你的 SSH 用户权限

但并不等于：

1
DSH 只能访问 Workspace 目录

如果需要更严格的隔离，真正可靠的方法依然是：

1
专用 Unix 用户
2
容器
3
虚拟机

而不是仅依靠 Workspace 路径。

6. 远程服务器到底需要哪些东西？#

测试主机时，你可能会看到类似：

1
bash  ✓
2
pwsh  ×
3
rg    ✓
4
code  ×

第一次看很容易误以为：

是不是四个都必须变成 ✓？

其实不是。

1
pwd
2
ls
3
python
4
git
5
npm
6
conda

1
base64
2
mkfifo

7. rg 是什么，为什么 DSH 需要它？#

rg 是：

1
ripgrep

DSH 会用它完成：

1
grep
2
glob
3
代码搜索
4
文件搜索

所以：

1
rg ×

并不是无关紧要的小问题。 如果 rg 不可用，Agent 的代码检索能力会受到明显影响。

8. 最容易踩坑的地方：你明明安装了 rg，DSH 却说没有#

这是我实际遇到的一个问题。 服务器中：

1
conda activate zx

之后：

1
which rg

输出：

1
/home/zhongxu/.conda/envs/zx/bin/rg

并且：

1
rg --version

完全正常。 看起来 rg 已经安装成功了。 但从本机测试：

1
ssh Server 'command -v rg'

却什么都没有。 为什么？

9. DSH 使用的不是你平时登录后的交互 Shell#

我们可以测试：

1
ssh Server 'echo "$PATH"'

得到：

1
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:...

里面根本没有：

1
/home/zx/.conda/envs/zx/bin

于是：

1
交互登录服务器
2
    ↓
3
conda activate zx
4
    ↓
5
rg ✅

但是：

1
DSH
2
   ↓
3
非交互 SSH
4
   ↓
5
没有 activate zx
6
   ↓
7
rg ❌

问题根本不在 rg。

问题在 PATH。

10. 真正的关键：.bashrc 顶部那个 return#

Ubuntu 默认的 ~/.bashrc 通常开头就有：

1
# If not running interactively, don't do anything
2
case $- in
3
    *i*) ;;
4
      *) return;;
5
esac

它的意思是：

如果当前不是交互 Shell，后面的 .bashrc 就不要继续执行了。

而 Conda 初始化一般在文件后面：

1
# >>> conda initialize >>>
2
...
3
# <<< conda initialize <<<

因此 DSH 通过非交互 SSH 执行命令时：

1
加载 ~/.bashrc
2
       ↓
3
发现不是 interactive
4
       ↓
5
return
6
       ↓
7
Conda 初始化根本没有执行

所以即使：

1
conda activate zx

后能找到 rg，DSH 还是看不到。

11. 我最终采用的 rg 解决方案#

我不建议让所有非交互 SSH 自动执行：

1
conda activate zx

因为这样等于把：

1
python
2
pip
3
其他二进制

全部偷偷切换到了 zx 环境。

更干净的方案是：

只把 DSH 真正需要的 rg 暴露出来。

首先创建个人用户命令目录：

1
mkdir -p ~/bin

然后建立软链接：

1
ln -sf /home/zx/.conda/envs/zx/bin/rg ~/bin/rg

现在结构就是：

1
~/bin/rg
2
    │
3
    └──► ~/.conda/envs/zx/bin/rg

接下来才是这次配置中非常关键的一步。

编辑：

1
nano ~/.bashrc

在文件最顶部、那个非交互 return 之前增加：

1
export PATH="$HOME/bin:$PATH"

最终类似：

1
export PATH="$HOME/bin:$PATH"
2

3
# ~/.bashrc: executed by bash(1) for non-login shells.
4

5
# If not running interactively, don't do anything
6
case $- in
7
    *i*) ;;
8
      *) return;;
9
esac

于是非交互执行过程变成：

1
SSH
2
 ↓
3
读取 ~/.bashrc
4
 ↓
5
export PATH="$HOME/bin:$PATH"
6
 ↓
7
遇到非交互 return
8
 ↓
9
停止加载其他环境

虽然 Conda 没有激活，但：

1
~/bin/rg

已经进入 PATH。

12. 验证 rg 是否真正解决#

不要只在服务器里运行：

1
rg --version

这不能证明 DSH 能看到它。

真正应该从本机测试：

1
ssh Server 'echo "PATH=$PATH"; echo "rg=$(command -v rg)"; rg --version | head -1'

正确结果应该类似：

1
PATH=/home/zx/bin:/usr/local/sbin:...
2
rg=/home/zhongxu/bin/rg
3
ripgrep 15.2.0

看到这里：

1
rg=/home/zx/bin/rg

才意味着：

DSH 的非交互远程环境真正能够找到 rg。

这也是我认为这一整套配置里最值得记录的坑之一。

13. code × 又是什么意思？#

下一项比较容易误解的是：

1
code ×

很多人第一反应可能是：

那是不是服务器必须安装完整 VS Code？

并不是。

Remote Workspace 需要的是：

1
VS Code Agent Host

插件会依次寻找：

1
1. PATH 中的 code
2

3
2. ~/.dsh-remote-ssh/cli/bin/code
4

5
3. 已经存在的 VS Code Server cache

这一 fallback 逻辑是插件明确实现的。

所以如果你以前使用过：

1
VS Code Remote - SSH

服务器可能早就已经有：

1
~/.vscode-server

14. 检查现有 VS Code Server#

执行：

1
ls -lah ~/.vscode-server

以及：

1
du -sh ~/.vscode-server

如果之前经常使用 Remote-SSH，这个目录可能已经非常大。

例如我的服务器已经有多个版本：

1
~/.vscode-server/cli/servers/
2
├── Stable-110a328...
3
├── Stable-a5b500...
4
├── Stable-c2d1b1...
5
├── Stable-df53da...
6
├── Stable-e4c7e7...
7
└── Stable-8761a5...

这是正常的。

它们本质上是不同 VS Code commit 留下来的 Server 版本。

15. 确认 code-server 是否存在#

可以直接执行与插件搜索逻辑基本一致的命令：

1
find "$HOME/.vscode-server/cli/servers" \
2
  -type f \
3
  -path '*/server/bin/code-server' \
4
  -perm -u+x \
5
  -printf '%T@ %p\n' 2>/dev/null \
6
  | sort -nr \
7
  | cut -d ' ' -f 2-

如果输出：

1
/home/user/.vscode-server/cli/servers/Stable-xxx/server/bin/code-server
2
/home/user/.vscode-server/cli/servers/Stable-yyy/server/bin/code-server
3
...

说明现有 VS Code Server 可以被插件检测到。

而且插件并不是只尝试最新版本。

它会从新到旧依次尝试不同缓存，因为：

1
新版 VS Code Server
2
        ↓
3
AHP 协议可能过新
4
        ↓
5
尝试旧版
6
        ↓
7
找到兼容版本

这个 fallback 也是源码明确设计的行为。

因此暂时不要随便把旧的 VS Code Server 全删掉。

虽然它们确实可能占掉几 GB 空间，但旧版本有时候恰恰可能成为 Remote SSH 的兼容 fallback。

16. 为什么 code × 也可能完全正常？#

这是另一个值得强调的地方。

如果 DSH 测试主机显示：

1
bash ✓
2
rg   ✓
3
code ×

并不能直接得出：

1
Remote Workspace 不可用

code × 很可能仅仅代表：

1
command -v code

失败了。

但插件仍然可以进一步找到：

1
~/.vscode-server/.../server/bin/code-server

并使用现有 VS Code Server 建立 AHP。

所以最终判断标准不应该只是 UI 那几个 ✓ / ×。

真正应该测试：

1
Remote Workspace 能否：
2

3
pwd
4
读取文件
5
列目录
6
grep
7
glob
8
执行 bash

如果这些都正常，那么：

VS Code Server fallback 已经工作了。

17. pwsh × 是否需要处理？#

如果你的服务器是 Linux：

1
pwsh ×

通常完全不用管。

pwsh 指的是：

1
PowerShell

对 POSIX/Linux Remote Workspace 来说，核心 Shell 是：

1
bash

上游也明确区分：

1
POSIX Remote Workspace → bash
2
Windows Workspace      → pwsh

当前远程 Workspace 主要支持 POSIX/Linux SSH 主机。

因此 Ubuntu 服务器最终类似：

1
bash  ✓
2
rg    ✓
3
pwsh  ×
4
code  ×

完全有可能已经可以正常工作。

18. SSH 本身也要先独立验证#

在折腾插件之前，我建议一定先保证：

1
ssh Server

本身可以正常连接。

例如：

1
Host Server
2
    HostName 10.122.xxx.xxx
3
    User user
4
    Port 22
5
    IdentityFile ~/.ssh/id_ed25519
6
    IdentitiesOnly yes

先测试：

1
ssh Server

再进入 DSH。

不要一开始就把：

1
SSH 配置问题
2
VPN 问题
3
密钥问题
4
DSH 插件问题
5
rg 问题
6
VS Code Server 问题

全部混在一起排查。

正确顺序应该是：

1
SSH
2
 ↓
3
Workspace 映射
4
 ↓
5
bash
6
 ↓
7
rg
8
 ↓
9
VS Code Server / Agent Host
10
 ↓
11
实际 Remote Workspace

19. 最终测试 Remote Workspace#

配置完成后，我比较推荐直接让 Agent 做一个无副作用测试：

1
请不要修改任何文件，只做环境检查：
2

3
1. 输出当前 pwd
4
2. 执行 command -v rg
5
3. 执行 rg --version
6
4. 列出当前工作区一级文件
7
5. 读取 README.md（如果存在）的前 20 行

如果结果类似：

1
pwd
2
/home/user/projects/aigc_detector
3

4
command -v rg
5
/home/user/bin/rg

同时：

1
目录可以列出
2
文件可以读取
3
rg 可以执行
4
bash 可以执行

那么整条链路实际上已经打通：

1
DSH Web
2
   │
3
   ▼
4
Remote Workspace
5
   │
6
   ▼
7
SSH
8
   │
9
   ▼
10
VS Code Server / AHP
11
   │
12
   ├── File System
13
   ├── Search
14
   ├── Bash
15
   └── Background Tasks
16
   │
17
   ▼
18
Remote Project

20. 最后总结：真正需要理解的几个关键点#

整个配置折腾下来，我认为最容易踩坑的并不是 SSH 本身，而是**“交互环境”和“DSH 远程执行环境并不是同一个环境”**。

尤其是下面这一行：

1
export PATH="$HOME/bin:$PATH"

以及它必须位于：

1
case $- in
2
    *i*) ;;
3
      *) return;;
4
esac

之前这一点，非常关键。

最终我自己的解决思路可以概括成：

1
第一步：SSH 本身必须能连接
2

3
第二步：把远程目录映射成 DSH Workspace
4

5
第三步：确认 bash 正常
6

7
第四步：安装 rg
8

9
第五步：
10
不要只测试交互式 rg，
11
而要测试非交互 SSH 能否找到 rg
12

13
第六步：
14
使用 ~/bin 暴露 rg
15

16
第七步：
17
在 ~/.bashrc 的 non-interactive return 前加入
18

19
export PATH="$HOME/bin:$PATH"
20

21
第八步：
22
如果 code ×，
23
先检查已有 ~/.vscode-server，
24
不要急着重新安装 VS Code
25

26
第九步：
27
实际测试 read / grep / bash / pwd，
28
而不是只盯着测试页面的 ✓ / ×

配置完成之后，最终得到的是一套我认为很舒服的远程开发结构：

1
┌───────────────────────────────┐
2
│           Local Mac           │
3
│                               │
4
│ DSH Web                       │
5
│ Model / Provider              │
6
│ Session                       │
7
│ Plugins                       │
8
│ Skills                        │
9
└───────────────┬───────────────┘
10
                │
11
             SSH / AHP
12
                │
13
┌───────────────▼───────────────┐
14
│        Remote Linux Server    │
15
│                               │
16
│ Project                       │
17
│ Data                          │
18
│ Conda                         │
19
│ Python                        │
20
│ Bash                          │
21
│ ripgrep                       │
22
│ GPU                           │
23
└───────────────────────────────┘

本地仍然是自己的 DSH。

服务器仍然是服务器。

项目不需要完整同步到本地。

模型也不需要使用另一套所谓的 remote_* 工具。

你切换的不是工具，而是 Workspace。

这也是 dsh-remote-ssh 这套设计最吸引我的地方。

1
https://github.com/Yan-Zero/dsh-remote-ssh

1
https://github.com/Zhong0118/dsh-remote-ssh