让 AI 客户端安全地操作你的服务器 —— 基于 SSH 的 MCP 服务器
通过标准化 MCP 工具在远端执行命令与传输文件，内置 Web 管理台与 Windows 托盘应用。
把 Claude Code、Cursor 等支持 MCP 协议的 AI 客户端连到你的 SSH 服务器上，AI 就可以：
⚙️ 执行命令 —— 远程运维、日志排查、服务管理
📤 上传 / 📥 下载文件 —— 配置分发、日志拉取、大文件断点续传
🖥️ 多机管理 —— 项目 → 环境 → 主机三级树，一次配置处处可用
两种使用形态，按需选择：
形态 | 适合场景 |
Windows 桌面应用（推荐） | 纯托盘常驻 + 内置 Web 管理台 + 在线自更新，零 Node.js 环境 |
CLI / npm 包 | 作为 stdio MCP Server 挂给任意 MCP 客户端，轻量即用 |
均以本地安装方式交付：不依赖每次启动去 npm registry 解析版本，内网 / 弱网环境同样可用。
Related MCP server: sshops
🔐 多种认证：密码 / 私钥（含加密私钥）/ SSH Agent / 键盘交互式 2FA
🔗 SOCKS5 与 HTTP(S) 代理，穿透跳板网络
🚄 双传输模式：
exec —— 每命令一通道，标准 Linux 主机
shell —— 持久会话 + 标记协议，适配堡垒机 / 跳板机
⏱️ 连接 / 命令 / SFTP 三级超时独立可控；大文件走 fastPut/fastGet 分片并发
命令白名单 / 黑名单（正则），主机级与全局级双层过滤
本地与远端路径白名单，约束文件传输范围
全量审计日志：命令、输出、传输记录可追溯
项目-环境-主机三级可视化管理，连接拖拽排序
测试连接、JSON 批量导入导出、~/.ssh/config 自动复用
定时备份快照与一键恢复；MCP 客户端（Claude Code 等）一键注册
明暗双主题，跟随系统切换
🎯 纯托盘单 exe：SSH 服务、MCP Server、Admin 静态站点全部内嵌，无 Node.js 依赖
开机自启、关机驻留；「打开管理页」直达系统默认浏览器
🔄 在线自更新：内置 minisign 验签，自动检测新版本静默升级
连接管理 —— 三级树管理全部主机：
系统页 —— 服务状态、MCP 客户端一键注册、自启动与应用更新：
从 Releases 下载 SSH-MCP-Server_x.x.x_x64-setup.exe 安装。启动后驻留系统托盘，托盘菜单「打开管理页」进入 Web 控制台，无需 Node.js 环境。
在管理台把项目 → 环境 → 主机配好后，进入 系统 → 一键注册，选择客户端（Claude / VS Code / Cursor）与作用域，即可把 MCP 客户端指向本机服务：
{
"mcpServers": {
"ssh-server": {
"type": "http",
"url": "http://127.0.0.1:61823/mcp"
}
}
}服务常驻复用，客户端配置一次即长期有效；主机增删改在管理台完成，保存即时生效，无需重启 MCP 会话。已安装用户升级由内置自更新完成（Releases + minisign 验签），也可在 系统 → 应用更新 手动检查。
npm install -g @keysqiu/ssh-mcp-server在 MCP 客户端中注册（以 Claude Code 为例）：
claude mcp add ssh-server -- ssh-mcp-server --host your.server.com --username root --password YOUR_PWD或直接写 JSON 配置：
{
"mcpServers": {
"ssh-server": {
"command": "ssh-mcp-server",
"args": ["--host", "your.server.com", "--username", "root", "--password", "YOUR_PWD"]
}
}
}此形态为传统 stdio MCP Server：客户端拉起子进程直连，不需要常驻服务。若想要 Web 管理台，用 ssh-mcp-server --admin 启动同一套管理台（http://127.0.0.1:61823/admin/），再由客户端连 http://127.0.0.1:61823/mcp。
为什么不用
npx：npx @keysqiu/ssh-mcp-server每次启动都要访问 npm registry 解析并下载版本，内网 / 弱网环境下经常卡住或失败。全局安装后包已在本地，启动不再联网取包。
配置文件与多连接模式详见 docs/migration.md 与 CLI 帮助（--help）。
git clone https://github.com/QiuZwan/ssh-mcp-server.git
cd ssh-mcp-server && npm install
npm run build # 构建 Node 版
npm test # 运行测试
npm --prefix admin-web install && npm run build:admin # 构建管理台前端
npm run build:tauri # 构建 Windows 桌面应用（含前端，需 Rust 工具链）工具 | 说明 |
| 远程执行命令，支持目录切换、超时与输出限制，受白/黑名单约束 |
| SFTP 文件传输，大文件分片并发，路径白名单校验 |
| 列出所有可用连接 |
┌─ Windows 桌面应用（Tauri 2 纯托盘单 exe）──────────────────┐
│ │
│ SSH 连接池 ── MCP StreamableHTTP (/mcp) │
│ │ │
│ Admin API (/admin/api/*) ── 内嵌静态站点 (/admin/) │
│ │
└────────────────── 系统默认浏览器打开管理页 ────────────────┘
Node 版（npm 包）：stdio MCP Server ＋ 可选 --admin 启动同一套 Web 管理台关键模块：src/services/ssh-connection-manager.ts（SSH 核心）、src/server/（Fastify Admin 服务）、src-tauri/（Rust 桌面壳）、admin-web/（React 管理台）。
ISC © SIE Operations and Maintenance Team
Download file from connected server
| Name | Required | Description | Default |
|---|---|---|---|
| localPath | Yes | Local path | |
| remotePath | Yes | Remote path | |
| connectionName | No | SSH connection name (optional, default is 'default') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that a file is downloaded from a connected server; it does not mention that localPath will be written, files may be overwritten, or that a valid connectionName is needed. This is a significant gap for a tool with side effects on the local filesystem.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. However, it may be underspecified for a tool that writes to the local filesystem, so it is not maximally effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no output schema and no annotations, the description is incomplete. It omits behavioral details such as overwrite behavior and default connection semantics (though connectionName is documented in the schema). An agent would need to infer several operational aspects beyond what is given.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already contains descriptions for all three parameters (localPath, remotePath, connectionName), and schema coverage is 100%. The description adds no additional parameter-level meaning, so the baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the precise operation ('Download file') and the source ('from connected server'), clearly identifying it as a remote-to-local transfer. It is distinct from siblings like upload, execute-command, and list-directory, though it does not explicitly distinguish itself by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as upload or list-directory. The description merely restates the operation and leaves the agent to infer selection criteria from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute command on connected server and get output result
| Name | Required | Description | Default |
|---|---|---|---|
| timeout | No | Command execution timeout in milliseconds (optional; overrides the connection's commandTimeoutMs or shellCommandTimeoutMs, which defaults to 30000ms) | |
| cmdString | Yes | Command to execute | |
| directory | No | Working directory for command execution | |
| connectionName | No | SSH connection name (optional, default is 'default') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only says commands are executed and output is returned; it fails to mention that this can run arbitrary, potentially destructive commands on the server, how timeouts or working directories affect execution, or what the output result contains (e.g., stdout, stderr, exit code).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that front-loads the core action and outcome with no redundant words. It is concise and well-structured, though it could have included more behavioral context without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a powerful command-execution tool with four parameters and no output schema, the description is incomplete. It does not explain return values, failure modes, side effects, or how parameters like directory and connectionName influence execution. Given the potential for destructive commands, more context is necessary for safe and correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for all four parameters, including default behavior for timeout and connectionName. The description text adds no additional parameter meaning, but the schema already documents each field adequately, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: "Execute command on connected server and get output result." This clearly conveys the tool's action and outcome, and it is immediately distinguishable from the sibling tools (upload, download, list-servers, list-directory), which all perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for running shell commands on a server versus the file transfer and listing operations of sibling tools, but it provides no explicit when-to-use guidance, prerequisites, or exclusions. Usage context is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List entries of a remote directory (name, type, size, mtime) via SFTP
| Name | Required | Description | Default |
|---|---|---|---|
| remotePath | Yes | Absolute POSIX directory path on the remote server, e.g. /var/log | |
| connectionName | No | SSH connection name (optional, default is 'default') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It does communicate that this is a list/read operation and what fields appear in the result, which is helpful. It doesn't mention behaviors like connection requirements, symlink handling, error conditions, or non-existent paths, but the core read-only nature is reasonably clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tight sentence that front-loads the action and resource, then adds the useful output-field detail. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool, the description plus fully documented schema covers the essential context: what is listed, what fields are returned, and how the path/connection parameters behave. It lacks explicit return format details and error behavior, but those are minor given the simplicity and lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both parameters fully, including path format and the optional default for connectionName. The description adds no new parameter-level semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('List'), a specific resource ('entries of a remote directory'), and the key returned attributes (name, type, size, mtime). It clearly distinguishes this tool from siblings like execute-command, upload, download, and list-servers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the description: when you need a directory listing over SFTP. However, there is no explicit guidance about when to prefer this over alternatives, no exclusions, and no mention of prerequisites such as needing a configured SSH connection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available SSH server configurations
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'List' implies a read-only operation, but the description does not clarify what 'available' means, whether the tool connects to servers, or what kind of configuration data is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. It communicates exactly what the tool does in the fewest words necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter listing tool, this description is mostly complete. It clearly identifies the action and resource, though adding the output format or clarifying what 'configurations' includes would make it fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema already covers everything relevant. With no parameters to explain, the baseline of 4 applies, and the description does not need to add parameter-level detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('list') and resource ('SSH server configurations'), making the tool's purpose immediately clear. It is also naturally distinct from sibling tools like execute-command, upload, download, and list-directory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention workflows such as 'use this before connecting to a server' or exclude cases where list-directory might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload file to connected server
| Name | Required | Description | Default |
|---|---|---|---|
| localPath | Yes | Local path | |
| remotePath | Yes | Remote path | |
| connectionName | No | SSH connection name (optional, default is 'default') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are completely absent, so the description carries the full burden of behavioral disclosure. It only states the basic action and does not mention whether an existing remote file is overwritten, whether directories are created, what permissions are required, or any side effects. This is a significant gap for a mutation-like upload operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is concise and front-loaded with the core action ('Upload file'), containing no filler. It effectively states the purpose in minimal words, though it could be slightly expanded with useful context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is too sparse. It does not explain what happens on success or failure, whether the remote path refers to a file or directory, or how the 'connected server' is determined. The schema covers parameter names but the overall operational context is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all three parameters, with 100% coverage, so the baseline applies. The description adds no additional parameter meaning, but because the schema fully covers 'localPath', 'remotePath', and 'connectionName', a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Upload file') and the target ('connected server'), which distinguishes it from siblings like 'download' or 'execute-command'. However, it does not explicitly differentiate from these siblings by naming them or elaborating on the remote context, so it misses the top score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives like 'download' or 'execute-command'. It does not mention prerequisites, such as needing an existing server connection, nor when not to use this tool. Usage is only vaguely implied by the verb 'Upload'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.1.3downloadexecute-commandlist-directorylist-serversuploadScored across 5 tools
Each tool targets a distinct operation: remote command execution, file upload, file download, server configuration listing, and directory listing. There is no meaningful overlap or ambiguity between them.
Naming mostly follows a clear verb-object pattern with lowercase hyphenation, like execute-command, list-servers, and list-directory. The standalone upload and download verbs deviate slightly from the hyphenated style but remain intuitive and consistent in intent.
Five tools is well-scoped for an SSH MCP server, covering the essential interactions without unnecessary bloat. Each tool earns its place and the set feels focused.
The set covers command execution, file transfer, directory browsing, and server enumeration, which are core SSH workflows. Minor gaps like missing explicit remote delete, rename, or mkdir tools are workable because command execution can handle those operations.
Egnyte's remote MCP server for secure AI access, search, upload and file management in your account.
Secure and manage MCP servers through the Speakeasy AI Control Plane from your agent.
Termalin's hosted MCP server. Claude, ChatGPT or any MCP client runs commands, moves files over SFTP, queries databases and reads server metrics and monitoring alerts on your servers, keylessly through Termalin Connectors: no SSH key is handed over and no inbound port is opened. Per-host command policy and an audit log. Needs a termal.in Pro or Team account (new accounts start with a 14-day Pro trial).
Compliance frameworks (SOC 2, ISO 27001, CMMC, NIST, more) delivered to AI agents as MCP tools.
