Security Concerns : The Lethal Trifecta

[codyaverett]

Have you considered how this might pose a significant security risk?

Like I think this MCP server is begging to be abused in some way as it would give an LLM access to arbitrary user data on the system.. be able to communicate out to the internet.. and who knows what else.

If you aren't already aware, there is this idea called the Lethal Trifecta that I think this type of MCP server exposes user to.

• https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
• https://simonwillison.net/2025/May/26/github-mcp-exploited/

I also don't think suggesting to use the root user in the examples is a good idea.

Just some thoughts, maybe put a bigger disclaimer up 😅
The one bit of text in the License section says "use at your own risk", but... we all know all people aren't going to read all the fine print.

[tufantunc]

Hi @codyaverett,

Thank you for opening this issue and for the detailed explanation of the security concerns — especially highlighting the "Lethal Trifecta" risks. I completely agree that the current design introduces significant dangers when LLM agents are given broad shell access, and prompt injection attacks could easily exploit this.

I'm taking these concerns very seriously and will be working on substantial security improvements in upcoming versions.
My goal is to mitigate these risks as much as possible while preserving the tool's core functionality.

I'm very open to ideas and suggestions from the community on how to make ssh-mcp safer. Please feel free to share your thoughts here.

Thanks again for the valuable feedback.

[codyaverett]

I was discussing with my friends @amosroger91 and @apage43
Few ideas off the top

• allow and deny list for commands that can be run.. similar to how agents can be given access to specific tools.
• limit command scopes
• force access to limited user accounts
• maybe force access to approved commands

From Claude Opus 4.5

● Excellent research. Now I have a clear picture. The SSH MCP server is indeed a textbook example of the Lethal Trifecta:

  1. Access to Private Data - Can read any file the SSH user has access to
  2. Exposure to Untrusted Content - LLM processes content from various sources
  3. External Communication - Can make outbound connections via curl, wget, nc, etc.

  Here are comprehensive mitigation ideas to add to your follow-up:

  ---
  Security Mitigation Ideas

  Command Filtering & Scoping

  - Allowlist/Denylist for commands - Configurable regex patterns or explicit command prefixes that are permitted/blocked
  - Tool-scoped execution - Instead of raw exec, expose purpose-specific tools like read-file, list-directory, run-linter that internally construct safe
  commands
  - Command templates - Pre-defined parameterized commands where the LLM can only fill in specific arguments (e.g., git log --oneline -n {count})

  Access Control

  - Dedicated low-privilege user accounts - Document/enforce that SSH users should have minimal permissions via sudoers restrictions, chroot jails, or rbash
  (restricted bash)
  - Read-only mode - A --readOnly flag that only allows commands that don't modify state
  - Per-session command budgets - Limit total commands or bytes of output per session

  Audit & Transparency

  - Command logging - Write all executed commands to a log file with timestamps
  - Human-in-the-loop confirmation - Optional mode requiring user approval before executing commands matching certain patterns (destructive ops, network calls)
  - Output redaction - Automatically redact known secret patterns (AWS keys, tokens) from output before returning to LLM

  Network Isolation

  - Outbound blocking - Document that target hosts should have firewall rules blocking outbound connections (or whitelist only)
  - Container/VM isolation - Recommend running target SSH sessions in ephemeral containers

  Prompt Injection Defenses

  - Command origin tagging - Mark which commands came from user prompts vs LLM reasoning
  - Dual-LLM verification - Have a second model review commands before execution (expensive but effective)

[codyaverett]

@tufantunc
Glad you see the importance and urgency here.
We gotta keep folks informed and safe 👍

Running this in a containerized namespace sounds nice .. limit the scope of system exposure.
Probably more of a training/learning thing for your users though 🤔

An agent having access to a users history could definitely be problematic.

Basically.. if anyone got access to this MCP server without permission you'd be up a creek without knowing it.
Consider very verbose logging/reporting!

If someone intercepted/replayed your remote LLM responses somehow... they could inject whatever commands they want onto your system... e.g. download a malicious package that gives them a real permanent back-door 😓

More from Opus 4.5

❯ Would the password and location of the ssh key be exposed to the llm at all?

● Good question. Let me check how credentials flow through the MCP server and what's exposed to the LLM client.

● Searched for 1 pattern, read 1 file (ctrl+o to expand)

● Short answer: No, credentials are not directly exposed to the LLM via the MCP protocol. But there are indirect exposure risks.

  How Credentials Flow

  CLI args (--password, --key) → parsed at startup → stored in SSHConnectionManager.sshConfig → used internally for SSH auth
                                                                      ↓
                                            LLM only sees: exec(command, description) → output

  The LLM interacts with the exec and sudo-exec tools, which only accept command and description parameters. The password/key values are never returned in tool
   responses.

  However, Indirect Exposure Risks Exist

  1. Process listing attack - The LLM could run:
  ps aux | grep ssh-mcp
  # or
  cat /proc/$(pgrep -f ssh-mcp)/cmdline | tr '\0' '\n'
  1. This would reveal --password=secret from the command line arguments.
  2. On the remote host - The LLM could explore:
    - ~/.ssh/ for keys
    - ~/.bash_history for credential patterns
    - Environment variables with env or printenv
    - Configuration files
  3. Sudo password in command - Looking at src/index.ts:487, the sudo password gets embedded in the command:
  wrapped = `printf '%s\\n' '${pwdEscaped}' | sudo -p "" -S sh -c '...'`;
  3. This appears in the command string sent to the remote server, potentially visible in process listings there too.

  Mitigations to Consider

  - Use SSH keys instead of passwords (but key path is still visible)
  - Use environment variables instead of CLI args: SSH_PASSWORD instead of --password
  - Run the MCP server in a container/namespace where /proc is restricted
  - On the remote host, use a locked-down user with no shell history and restricted filesystem access