Agent接入SSH：权限与审计怎么选

让 AI 通过 SSH 操作服务器，难点不在能否执行命令，而在谁保管密钥、危险命令能否提前拦住、出了问题能否追查。原文把 SSH MCP 项目分成独立服务、远程连接器和客户端内置服务三类，建议先确定凭据归属，再选工具。

作者参与开发 Termalin，文中其他项目的信息来自公开仓库和文档，核对日期是 2026 年 10 月 14 日。这是一份带有厂商视角的选型整理，没有性能或安全对照实验。

独立服务够轻，但权限控制要逐个看

独立 SSH MCP 服务的用法很直接：配置主机和密钥，启动服务，再让 Agent 连接。没有 GUI，适合无桌面环境，也便于脚本管理。

这一类里，作者最认可 tufantunc/ssh-mcp：约 800★、MIT 许可证、TypeScript 实现，提供 14 个工具。它的 v2 加入了四类命令分类：read-only / safe / destructive / privileged；还有 RBAC 角色 viewer / operator / admin、审批模式、带脱敏的审计日志，以及主机密钥固定校验（host-key pinning）。

这些功能分别回答了三个实际问题：哪些命令风险更高，谁有资格执行，以及执行后留下什么记录。主机密钥固定校验则用于核对连接目标的身份。

其他项目更偏向复用现有 SSH 工作流：

• AiondaDotCom/mcp-ssh，也叫 MCP SSH Agent，读取 ~/.ssh/config 和 known_hosts，调用原生 ssh。
• blackaxgit/ssh-mcp 同样读取 ~/.ssh/config，增加服务器分组，方便管理多台机器。
• veithly/ssh-client-mcp 同时提供 SSH、SFTP，支持密码和密钥认证。
• idletoaster/ssh-mcp-server 使用 Node，基于官方 MCP SDK。
• the-nine-nation/remote-ssh-mcp 通过本地 OpenSSH 提供持久、有状态的会话。
• MaraBank 的 claude-ssh-mcp 支持 pip/npx，采用在聊天中粘贴密码的使用方式，启动方便，但凭据会直接进入聊天链路。

这类服务通常把密钥放在自身运行的位置，常见形式是 Agent 可触及的普通密钥文件；审计也往往依赖事先配置的日志。作者把 tufantunc/ssh-mcp v2 列为例外，但没有展开它具体怎样隔离密钥，不能据此认定其所有部署方式都能让 Agent 接触不到凭据。

电脑关机后还能连接，代价是多一条信任链

如果 Agent 在在线聊天服务或 CI 中运行，本地启动一个 SSH 包装服务还不够：电脑关机后，入口也就消失了。

browser-ssh 提供远程 MCP 地址 api.browserssh.com/mcp，宣称能对已保存服务器执行受范围约束、可审计的 SSH 命令、会话和 SFTP 操作，同时不向 Agent 暴露凭据。使用者通过 URL 接入。

sshrew（duriantaco）则是自托管路线：目标机器通过 cloudflared 主动建立出站连接，再把得到的 URL 填入 Claude 的自定义连接器。它提供命令白名单，以及只读共享根目录 ~/.sshrew-share。

两者都把凭据放在服务端或建立出站连接的机器上。Agent 拿不到密钥，并不等于连接链路里没有凭据或信任成本。

对 browser-ssh，需要信任第三方服务；对 sshrew，需要维护自托管机器和隧道路径。这里解决的是远程可达性与凭据位置问题，不能仅凭「托管」两个字推断权限控制更强。

客户端内置 MCP，把人工观察也纳入操作链路

第三类把 SSH 客户端和 MCP 服务放进同一个产品，适合既要 Agent 操作，也要人查看执行过程的场景。

Conduit 内置本地 MCP 服务，通过 socket/pipe 通信，约 60 个工具，使用 Apache-2.0 许可证。XPipe 提供本地 HTTP 端点，默认只读。两者都没有云端 MCP 入口。原文据此强调本地性，但「没有云端端点」不足以证明整个产品绝无数据外发，文中没有提供完整的数据流分析。

Termalin 同时提供本地服务和托管入口：本地 22 个工具，远程 https://termal.in/mcp 提供 21 个工具，通过 OAuth 支持 claude.ai、ChatGPT、Claude Code、Codex 和 Cursor。

按作者描述，Termalin 的 MCP 服务充当密钥托管者（key custodian），代替 Agent 完成签名，不把密钥交给 Agent；它通过出站 Connector 提供免密钥接入，并按连接执行 full / allowlist / read-only 策略，记录审计日志。产品还提供实时观察网格和带 Agent 标记的审计记录。

这里的「免密钥」需要结合上下文理解：Agent 不必接收密钥，连接仍然存在认证与授权机制。原文没有展开 Connector 的完整认证流程。

我的判断

我赞同先问「谁持有凭据」，再比较工具数量。14、21、22 或约 60 个工具，描述的是接口规模，无法直接说明权限边界是否可靠。

但凭据归属只是第一问。密钥即使被妥善托管，Agent 如果能调用一个无限制的命令执行接口，仍然拥有很大的操作权限。选型还应看策略是否在执行前强制生效，以及审批、日志能否覆盖实际使用的入口。

原文没有给出命令分类准确率、白名单绕过测试、审计完整性或长期运行数据。「最值得选」「认真对待策略」等评价，应视为作者依据文档作出的判断。尤其作者自身开发 Termalin，其产品描述不能当成独立安全评估。

独立服务也不天然弱于客户端方案。前者便于做成小而清晰的部署单元，后者便于人工观察和集中管理。哪种合适，取决于团队已有的 SSH 配置、运行环境和操作流程。

能拿来做什么

• 给 Claude Code、Codex 或 Cursor 接入远程开发机之前，先明确私钥存在哪里、Agent 能否读取文件，以及命令最终由哪个进程执行。
• 已有 ~/.ssh/config、只需少量远程查询的团队，可以先评估原生 ssh 包装方案，同时确认日志是否开启、允许执行哪些命令。
• 需要从聊天服务或 CI 访问服务器时，先确定入口能否持续在线，再比较第三方托管与 cloudflared 自托管的维护成本和凭据归属。
• 评估 tufantunc/ssh-mcp v2 或客户端内置方案时，用自己的常用操作核对角色、审批和每连接策略；检查默认只读是否真正约束了所需入口。