Securely Execute Remote SSH Commands

A bridge tool that lets AI assistants and other MCP-compliant applications execute remote SSH commands through a standardized interface - so an assistant can operate a remote server and get results back without SSH credentials ever being exposed to the AI model. Four tools: execute-command runs an SSH command on the remote server and returns the result; upload/download transfer files to/from the server; list-servers lists all configured SSH server connections.

Supports password and private-key authentication (including passphrase-protected keys), and two transport modes (exec and shell) covering both direct hosts and bastion/jump-host setups. Basic password config:

{
 "mcpServers": {
 "ssh-mcp-server": {
 "command": "npx",
 "args": ["-y", "@fangjunjie/ssh-mcp-server", "--host", "192.168.1.1", "--port", "22", "--username", "root", "--password", "pwd123456"]
 }
 }
}

Private-key auth is configured the same way with --privateKey ~/.ssh/id_rsa in place of --password. Runs via npx, no global install needed. Claude Code users can alternatively install the bundled ssh-mcp-helper skill, which walks through Node.js checks, client selection, auth method, and connection parameters interactively and writes the config for you.

Anyone who wants an AI assistant to run commands or move files on a remote server, with credentials managed entirely on the local side and a flexible allow/deny list controlling exactly which commands are permitted.

Reuse an existing ~/.ssh/config host alias instead of repeating connection params:

{ "mcpServers": { "ssh-mcp-server": { "command": "npx", "args": ["-y", "@fangjunjie/ssh-mcp-server", "--host", "myserver"] } } }

which picks up HostName/Port/User/IdentityFile from the matching Host myserver block (a custom SSH config file path can be given via --ssh-config-file; command-line arguments always take priority over values from the SSH config). When the target host is only reachable through a proxy, --proxy accepts a SOCKS5, HTTP, or HTTPS proxy URL, e.g. --proxy http://username:password@proxy-host:proxy-port, for jump-host and bastion scenarios beyond the direct dual-transport support already mentioned.

--whitelist and --blacklist restrict which commands the server will execute, each a comma-separated list of regex patterns; strongly recommended for production. The whitelist matches against the FULL command, and when a whitelist is active, any command containing ;, &, |, backticks, $(), >, <, or a newline is rejected outright - command chaining, piping, redirection, or substitution can't be used to bypass it. Example whitelist allowing only read-only inspection commands:

--whitelist "^ls(?: [A-Za-z0-9_./-]+)*$,^cat [A-Za-z0-9_./-]+$,^df(?: -[A-Za-z]+)*(?: [A-Za-z0-9_./-]+)?$"

Example blacklist blocking dangerous commands:

--blacklist "^rm .*,^shutdown.*,^reboot.*"

If both are set, a command must pass the whitelist AND not match the blacklist to run. For anything needing to chain multiple operations, the recommended pattern is a separately-reviewed script that's the only thing allow-listed, rather than parsing shell syntax by hand.

A --command-template wraps every executed command in a template - useful for switching users (su), running inside a container, or working through a jump host. <quotedCommand> inserts the command as a shell-quoted argument; <command> inserts it verbatim; the template applies AFTER any directory cd is concatenated, so the whole cd ... && <command> gets wrapped. E.g. --command-template "su root -c <quotedCommand>" turns ls /app (run in /data) into su root -c 'cd -- '\''/data'\'' && ls /app'.