Skip to main content
Glama
danielecr

SSH Real MCP Server

by danielecr
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Local

SSH Real MCP Server

A Model Context Protocol (MCP) server that enables SSH remote command execution by delegating entirely to the system ssh binary. This means ssh-agent, ProxyCommand, ~/.ssh/config, jump hosts, and every other OS-level SSH feature work out of the box — no Node.js crypto, no native addons.

How it works

Instead of implementing the SSH protocol in Node.js, this server spawns ssh as a child process and pipes the output back to the MCP client. Authentication, key discovery, and connection routing are handled by your OS, exactly as if you ran ssh yourself in a terminal.

Requirements: ssh must be installed and available in PATH (standard on macOS and Linux).

Related MCP server: terminal-mcp-server

Features

  • Zero auth config — uses your existing ssh-agent, ~/.ssh/config, and key files automatically

  • ProxyCommand / jump hosts — works natively, no special parameters needed

  • Connectivity test — ssh_test tool to verify reachability before running commands

  • Argument injection protection — host and username are validated before being passed to ssh

  • Configurable timeout — commands are killed and an error is returned if they exceed the timeout

  • Detailed results: stdout, stderr, and exit code

Installation

From npm

npm install -g @danielecr/realssh-mcp

From source

git clone https://github.com/danielecr/realssh-mcp.git
cd realssh-mcp
npm install
npm run build

VS Code / Copilot configuration

After installing the package globally, add the server to your MCP configuration. In VS Code, open the MCP config file via Command Palette → MCP: Open User Configuration and add:

{
  "servers": {
    "realssh": {
      "type": "stdio",
      "command": "realssh-mcp"
    }
  }
}

Then run MCP: List Servers to verify the server is active.

Tools

ssh_execute

Execute a command on a remote server via SSH.

Parameters:

  • host (string, required): SSH server hostname or IP address

  • command (string, required): Command to execute on the remote server

  • username (string, optional): SSH username. Defaults to the current OS user

  • port (number, optional): SSH server port (default: 22)

  • timeout (number, optional): Command timeout in milliseconds (default: 30000)

  • agentForward (boolean, optional): Enable SSH agent forwarding -A (default: false)

  • extraArgs (string[], optional): Extra SSH arguments (e.g., ["-o", "StrictHostKeyChecking=no"])

Example:

{
  "host": "prod-web-01",
  "command": "df -h"
}
{
  "host": "192.168.1.100",
  "username": "deploy",
  "command": "systemctl status nginx"
}

ssh_test

Test SSH connectivity to a remote host (runs echo ok and checks the response).

Parameters:

  • host (string, required): SSH server hostname or IP address

  • username (string, optional): SSH username

  • port (number, optional): SSH server port (default: 22)

  • extraArgs (string[], optional): Extra SSH arguments

Host configuration

Hosts, aliases, jump hosts, and identity files are configured in ~/.ssh/config — not in the MCP server. This is intentional: the OS ssh binary reads that file natively.

Example ~/.ssh/config:

Host prod
    HostName prod.example.com
    User deploy
    ProxyJump bastion

Host bastion
    HostName bastion.example.com
    User admin
    IdentityFile ~/.ssh/bastion_ed25519

With the above config, "host": "prod" works with no extra parameters.

Security considerations

  • Commands are executed on remote systems with the privileges of the SSH user — ensure proper access controls on the remote side.

  • BatchMode=yes is set by default, preventing the ssh process from hanging on interactive prompts.

  • Host and username inputs are validated to prevent SSH option injection.

  • Command output may contain sensitive data; treat it accordingly.

License

MIT

Available Tools

2 tools
ssh_executeA

Execute a command on a remote server via SSH and return the output. Uses the system SSH binary so ssh-agent, ProxyCommand, and ~/.ssh/config are honoured automatically.

ParametersJSON Schema
NameRequiredDescriptionDefault
hostYesSSH server hostname or IP address (e.g., 'dev234' or '192.168.1.100')
portNoSSH server port (default: 22)
usernameNoSSH username (e.g., 'username'). Defaults to the current OS user.
commandYesCommand to execute on the remote server
timeoutNoCommand timeout in milliseconds (default: 30000)
agentForwardNoEnable SSH agent forwarding (default: false)
extraArgsNoExtra SSH arguments (e.g., ['-o', 'StrictHostKeyChecking=no'])

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses that it uses the system SSH binary and honors ssh-agent, ProxyCommand, and config. However, missing details on error handling, stderr capture, exit codes, and output format beyond 'return the output'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler. The first sentence states purpose, the second adds important behavioral context. Efficiently structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, yet the description does not specify the return format (stdout/stderr, exit code). Parameter description is covered, but output behavior is left vague, reducing completeness for a tool with 7 parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description does not add significant meaning beyond the parameter descriptions already present.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool executes a command via SSH and returns output. It distinguishes from the sibling ssh_test by focusing on command execution rather than connectivity testing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus ssh_test or alternatives. The description implies usage but lacks 'when not to use' or explicit context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ssh_testB

Test SSH connectivity to a remote host. Verifies that the system SSH binary can reach the host using the current agent/config.

ParametersJSON Schema
NameRequiredDescriptionDefault
hostYesSSH server hostname or IP address
portNoSSH server port (default: 22)
usernameNoSSH username. Defaults to the current OS user.
extraArgsNoExtra SSH arguments

TDQS

B3.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description bears full responsibility for behavior disclosure. It fails to specify what the test entails (e.g., does it attempt authentication?), what constitutes success or failure, and how errors are reported. The mention of 'current agent/config' is helpful but insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, consisting of two sentences with no unnecessary words. It is front-loaded with the primary purpose and follows with a clarifying statement.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema and annotations, the description should explain the return value and behavior on failure. It does not state whether the tool returns a boolean, throws an error, or provides diagnostic output, leaving the agent without critical usage context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents each parameter. The description adds minimal additional semantic value, merely restating the overall purpose. It does not elaborate on the meaning of extraArgs or username defaults beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: testing SSH connectivity and verifying reachability. It effectively distinguishes from the sibling tool ssh_execute by focusing on connectivity testing rather than command execution.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

While the description implies use for pre-execution connectivity checks, it lacks explicit guidance on when to use this tool versus ssh_execute or when not to use it. No prerequisites or exclusions are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0
Disambiguation5/5

ssh_execute and ssh_test have distinct purposes: executing a command vs. testing connectivity. There is no overlap, so an agent can easily choose the correct tool.

Naming Consistency5/5

Both tools follow the consistent pattern ssh_verb with snake_case, making them predictable and easy to understand.

Tool Count2/5

With only two tools, the server feels too sparse for an SSH utility. Common operations like file transfer, session management, or port forwarding are missing, making the set incomplete for many use cases.

Completeness2/5

The tool surface covers only command execution and connectivity testing, leaving major gaps such as file operations (scp/sftp), port forwarding, or interactive sessions. This is insufficient for a general-purpose SSH server.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Scout MCP

    jmagar
    F
    license
    Not graded
    quality
    D
    maintenance
    Enables remote file operations and command execution across multiple machines via SSH. Supports reading files, listing directories, and running commands on any host configured in your SSH config.

  • mcp-ssh-remote

    JasonLinjc
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables executing commands on remote SSH hosts, with full support for bastion/jump hosts and ~/.ssh/config, plus Slurm job management and rsync.
    3
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/danielecr/realssh-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server