Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Alolite SSH MCP Server run 'df -h' on prod-web-01"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that enables SSH remote command execution on remote machines with persistent connections. This server provides a secure way to connect to remote servers, execute commands, and retrieve output through the MCP protocol while maintaining long-lived SSH sessions for improved performance.
Persistent SSH connections - Maintains long-lived SSH sessions for better performance
Automatic connection management - Reuses connections, automatically reconnects if lost
Connection pooling - Manages multiple SSH connections efficiently
Execute commands on remote servers via SSH
Automatic SSH key discovery - Works like standard ssh command, automatically finds keys in ~/.ssh/
Support for both SSH key and password authentication
SSH agent forwarding support
Configurable connection timeouts
Detailed command execution results including stdout, stderr, and exit codes
Connection monitoring - Track active connections, idle times, and connection status
Graceful cleanup - Automatic cleanup of stale connections and graceful shutdown
Error handling and reporting
Related MCP server: MCP SSH Server
npm install -g @alolite/ssh-mcpClone the repository:
git clone <repository-url>
cd ssh-mcpInstall dependencies:
npm installBuild the project:
npm run buildThe server exposes two main tools: ssh_execute and ssh_connections
Execute a command on a remote server via SSH with persistent connections, just like using ssh -A username@hostname.
Key Benefits of Persistent Connections:
First command to a server establishes the connection
Subsequent commands reuse the existing connection (much faster)
Connections are automatically maintained and monitored
Automatic reconnection if connection is lost
Connection cleanup after 30 minutes of inactivity
Parameters:
host (string): SSH server hostname or IP address (e.g., 'dev234', '192.168.1.100')
username (string): SSH username (e.g., 'username')
command (string): Command to execute on the remote server
port (number, optional): SSH server port (default: 22)
privateKeyPath (string, optional): Path to SSH private key file (default: auto-discovered from ~/.ssh/)
passphrase (string, optional): Passphrase for the private key (if required)
password (string, optional): SSH password (only if not using SSH keys)
timeout (number, optional): Connection timeout in milliseconds (default: 10000)
agentForward (boolean, optional): Enable SSH agent forwarding (default: true)
Manage and monitor SSH connections in the connection pool.
Parameters:
action (string): Action to perform:
"list": List all active connections with status
"close": Close a specific connection
"close_all": Close all connections
connectionKey (string, optional): Connection identifier (username@host:port) - required for "close" action
Usage Examples:
// List all active connections
{
"action": "list"
}
// Close a specific connection
{
"action": "close",
"connectionKey": "username@host:22"
}
// Close all connections
{
"action": "close_all"
}Authentication Priority:
If password is provided, use password authentication
Otherwise, use SSH key authentication (default behavior):
If privateKeyPath is specified, use that key
If not specified, automatically discover keys from ~/.ssh/ directory
Tries common key names: id_rsa, id_ed25519, id_ecdsa, id_dsa
Simple Usage Examples for ssh_execute:
// Basic command execution (like: ssh username@host 'ls -la')
// First run establishes connection, subsequent runs reuse it
{
"host": "host",
"username": "username",
"command": "ls -la"
}
// Second command on same server (reuses connection - much faster!)
{
"host": "host",
"username": "username",
"command": "pwd"
}
// Check disk space on production server
{
"host": "prod-web-01.company.com",
"username": "deploy",
"command": "df -h"
}
// Run a command with specific SSH key
{
"host": "staging-db",
"username": "dbadmin",
"privateKeyPath": "/home/user/.ssh/staging_rsa",
"command": "systemctl status postgresql"
}Add this to your VSCode configuration:
{
"servers": {
"alolite-ssh-mcp": {
"command": "npx",
"args": ["-y", "alolite-ssh-mcp", "@alolite/ssh-mcp"]
}
}
}Credentials: This server requires SSH credentials to function. Be cautious about how credentials are provided and stored.
Command Execution: The server can execute arbitrary commands on remote systems. Ensure proper access controls.
Network Security: SSH connections are encrypted, but ensure you're connecting to trusted hosts.
Logging: Sensitive information like passwords are not logged, but command output may contain sensitive data.
MIT
Manage SSH connections (list active connections, close connections, get connection status)
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform: list active connections, close specific connection, or close all connections | |
| connectionKey | No | Connection key (username@host:port) for close action |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure, but it adds no context beyond the schema. It doesn't mention side effects of closing connections, requirements for the connectionKey parameter, or what the tool returns. The listed actions merely mirror schema values and include an unsupported one.
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 concise sentence, but it is under-specified for a multi-action tool and includes an unsupported action ('get connection status'). The structure is front-loaded enough, but the content lacks precision and completeness.
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 three distinct actions, no annotations, and no output schema, the description fails to explain action selection, parameter dependencies, or expected results. It only gives a high-level verb and a partially inaccurate parenthetical list, leaving the agent to infer critical usage details from the schema alone.
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?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning about the 'action' and 'connectionKey' parameters—it doesn't clarify that connectionKey is only required for 'close' or that 'list' ignores it. The schema's parameter descriptions already handle the basics.
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 identifies the resource (SSH connections) and uses 'Manage' as a verb, but it lists 'get connection status' as an action not present in the schema's enum (list, close, close_all). This makes the purpose partially misleading, though the core domain is evident.
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 given on when to use 'list' versus 'close' versus 'close_all', nor any comparison to the sibling tool 'ssh_execute'. The description simply enumerates example actions without explaining selection criteria or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a command on a remote server via SSH and return the output
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | SSH server hostname or IP address (e.g., 'dev234' or '192.168.1.100') | |
| port | No | SSH server port (default: 22) | |
| command | Yes | Command to execute on the remote server | |
| timeout | No | Connection timeout in milliseconds (default: 10000) | |
| password | No | SSH password (only if not using SSH keys) | |
| username | Yes | SSH username (e.g., 'username') | |
| passphrase | No | Passphrase for the private key (if required) | |
| agentForward | No | Enable SSH agent forwarding (default: true) | |
| privateKeyPath | No | Path to SSH private key file (default: ~/.ssh/id_rsa, ~/.ssh/id_ed25519, etc.) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses that the tool executes a command and returns output, but it does not mention potential side effects, security implications, blocking behavior, or error/exit code handling. For a remote command executor, this is insufficient transparency.
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 one concise sentence that states the core purpose without unnecessary filler. It is front-loaded with the action and resource, making it easy to parse.
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?
Despite moderate complexity (9 parameters, no output schema), the description only explains that output is returned without detailing its format, exit codes, or failure modes. It also omits usage context like ssh key requirements or typical scenarios. The description is too thin to be considered complete.
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 9 parameters, each with a meaningful description. The main description adds no extra parameter semantics, so the baseline of 3 is appropriate since the schema already does the heavy lifting.
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: execute a command on a remote server via SSH, and the expected result: return the output. This specifically differentiates it from the sibling tool `ssh_connections`, which likely focuses on connection lifecycle, not command execution.
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 `ssh_connections` or other alternatives, nor does it mention any prerequisites (e.g., SSH keys or reachable host) or cases where it should not be used. A clear 'when to use' statement is missing.
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. Dates show when Glama detected each change.
v1.0.4ssh_connectionsssh_executeThe two tools are clearly distinct: one executes commands, the other manages connections. There is no overlap or ambiguity between them.
Both tools share the 'ssh_' prefix, but 'ssh_execute' is a verb while 'ssh_connections' is a noun. This inconsistency in verb/noun pattern makes the naming slightly mixed, though still readable.
With only two tools, the server feels minimal. While the scope is narrow (SSH command execution and connection management), the modest count is borderline—not quite enough to feel comprehensive, but not excessive.
The tool set covers executing commands and managing existing connections, but lacks common SSH operations like creating new connections or transferring files. These gaps are significant for a server intended to provide SSH functionality.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Scoped, audited SSH exec, sessions, and SFTP on your saved servers without exposing credentials
Remote shell and detached long-running jobs on your own machines — no SSH, open ports or VPN.
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Secure tunneling, reverse proxy and remote access for local applications.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jppradhan/ssh-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
