SSH MCP Server

@yawlabs/ssh-mcp

One click adds this to your local Yaw MCP config so it's available in every Yaw Terminal session. Or install manually below.

Make SSH work for AI tools. MCP server that manages your SSH environment, diagnoses what's broken, fixes it, and gives your agent remote access to anything.

Built and maintained by Yaw Labs.

The problem

AI CLI tools run in subprocesses where SSH is constantly broken. The agent tries to git pull and gets Permission denied (publickey). It tries to SSH into a server and the agent socket is stale. It tries to deploy and the host key changed because the instance was recreated. Every time, the AI has no idea what's wrong and spirals.

This happens across every situation that needs SSH keys:

• Git — clone, pull, push, fetch, submodules, LFS
• Package managers — npm install, pip install, go get, cargo, composer from private repos
• Server access — SSH, SCP, SFTP, rsync
• Tunneling — port forwarding to databases, SOCKS proxies
• Deployment — Ansible, Terraform, Capistrano, deploy scripts
• Cloud — AWS EC2, GCP, Azure, DigitalOcean, any VPS

ssh-mcp fixes this. It manages the SSH agent, loads keys, diagnoses failures with actionable fix commands, and provides remote operations — all as MCP tools your AI agent can call.

Quick start

Add to your MCP client config:

{

"mcpServers": { "ssh": { "command": "npx", "args": ["-y", "@yawlabs/ssh-mcp@latest"] } } }

On Windows wrap with cmd /c since Node 20+ can't spawn .cmd files directly:

{

"mcpServers": { "ssh": { "command": "cmd", "args": ["/c", "npx", "-y", "@yawlabs/ssh-mcp@latest"] } } }

The @latest tag makes npx re-resolve against the registry on every spawn, so each MCP session uses the newest published version. Or install globally if you'd rather pin (no auto-update):

npm install -g @yawlabs/ssh-mcp

then in client config: "command": "ssh-mcp"

Tools

SSH environment management

Tools that fix your local SSH setup so everything else — git, deploys, tunnels — stops breaking.

Diagnostics

Remote operations

Higher-level operations

Tools that wrap common patterns agents build with ssh_exec — faster and less error-prone.

Auto-diagnostics

When any remote operation fails, ssh-mcp automatically runs diagnostics and includes the results in the error response. Your agent doesn't need to call ssh_diagnose separately — it gets told what's wrong and how to fix it right in the error message.

Connection pooling

Remote operations reuse SSH connections automatically. When your agent makes multiple calls to the same host, the first call opens a connection and subsequent calls reuse it. Connections are kept alive for 60 seconds after the last use, then closed automatically.

The pool caps at 100 connections by default, and a connection still being dialed counts against the cap. When the cap is reached the pool closes an idle connection to make room. If every slot is in use or dialing, a tool call waits for one instead of failing:

• A single-host remote tool (ssh_exec, the SFTP tools, ssh_find, ssh_tail, ssh_service_status) waits up to its timeout (30s for the SFTP tools, which have no timeout parameter) and is next in line for the first slot that frees, so an ssh_exec arriving in the middle of a wide ssh_multi_exec runs between two of its hosts rather than being refused for the whole run. It reports Connection pool is full only if it never won a slot in that time.
• `ssh_multi_exec` runs at most SSH_MCP_MAX_POOL_SIZE hosts at once (default 100) and works through a longer list as slots free up, so raising the cap raises its parallelism; timeout is per host, not a bound on the whole call. When the pool is full it waits, and gives up only when none of its own hosts holds a slot and a full timeout has passed with none of them starting or finishing. The hosts waiting at that point (up to one per parallel slot) and every host still queued then report Connection pool is full; the queued ones are never attempted.

A call reaches Connection pool is full only when other calls — a long ssh_exec, a concurrent ssh_multi_exec — kept every slot from it for a full timeout; a fan-out wider than the cap that has the pool to itself never does, however long it runs. If you see it, rerun once those calls finish (for ssh_multi_exec, the hosts that reported it), or raise the cap with SSH_MCP_MAX_POOL_SIZE= in the server's environment. The error names the variable.

The library's acquire() / withConnection() do not wait by default: they reject at once with a PoolFullError (code: "ERR_SSH_MCP_POOL_FULL", isPoolFullError()) unless you pass { waitForCapacityMs } — see Programmatic usage.

SSH config support

All connections respect your ~/.ssh/config. Host aliases, custom ports, usernames, identity files, and ProxyJump settings are used automatically. If you have Host myserver configured in your SSH config, just pass host: "myserver" — ssh-mcp resolves everything.

ProxyJump / bastion hosts are supported automatically. If your SSH config has ProxyJump bastion for a host, ssh-mcp connects through the bastion transparently. Chained proxies work too.

Host key verification

All remote operations verify the server's host key against ~/.ssh/known_hosts:

• Known host, key matches — accept.
• Known host, key changed — reject (MITM protection). The rejection message distinguishes a genuine key mismatch from "the server offered a key type your known_hosts entry doesn't cover", so a missing ed25519 line doesn't read as an attack.
• Unknown host — accept, unless strict mode is on (SSH_MCP_STRICT_HOSTKEYS=1).

That last branch is trust-always, not TOFU. Real trust-on-first-use pins the key it saw the first time and rejects a change afterwards. The connection path never writes to known_hosts — no tool adds an entry as a side effect of connecting — so connecting pins nothing: *every* connection to a host absent from known_hosts is a "first" use and is accepted, including one where an attacker swapped the key since your last call. Only hosts put into known_hosts out of band get mismatch protection — by you, by ssh-keyscan, or by ssh_known_hosts_fix, the one tool here that does write the file. Call it explicitly to add an entry so future changes are caught.

For stricter environments, set SSH_MCP_STRICT_HOSTKEYS=1 (or true, case-insensitive) to reject unknown hosts. Add them explicitly with ssh_known_hosts_fix first. The older name SSH_MCP_STRICT_HOST_KEY still works and accepts the same values, but prefer the new one: credential scanners such as Yaw MCP's doctor treat any name with a _KEY segment as a secret, and flag the old name as a plaintext credential.

The diagnostic tools (ssh_test, ssh_diagnose) use StrictHostKeyChecking=no for their probe commands. Those probes only run echo SSH_OK — no credentials or data pass through — so the relaxed setting is safe for connectivity testing. Real operations always go through the hostVerifier.

Command policy

ssh_exec and ssh_multi_exec accept free-form shell commands from the agent. For security-conscious deployments, you can restrict which commands run via two env vars, each accepting a comma-separated list of regex patterns:

• SSH_MCP_COMMAND_WHITELIST — if set, the command must match at least one pattern, else it's blocked.
• SSH_MCP_COMMAND_BLACKLIST — if set, the command must not match any pattern, else i