[Security Audit] AgentWard Permission Analysis — SSH Manager MCP Server

[Ratnaditya-J]

Hey — I reviewed mcp-ssh-manager's permission surface and wanted to flag some things. This is one of the highest-risk MCP server categories (remote shell access to production infrastructure), so the findings here are more about hardening than bugs.

TL;DR

37 tools give an agent unrestricted SSH access including arbitrary command execution, sudo escalation, file transfers, SOCKS proxy tunneling, and multi-server group execution. There are no command filters, path restrictions, or approval gates. A prompt injection could execute commands across an entire server fleet in a single tool call.

Top Findings

1. Unrestricted remote command execution (CRITICAL)

ssh_execute passes any command string to the remote server with zero filtering. ssh_execute_group amplifies this across all servers simultaneously. No allowlist, no blocklist, no approval step.

2. Sudo with stored passwords (CRITICAL)

ssh_execute_sudo accepts a password parameter directly from the agent, or uses a password stored in plaintext in .env. The password is passed via echo "$password" | sudo -S, which exposes it in the process list. The agent gets root access with no confirmation.

3. SSH tunneling including SOCKS proxy (CRITICAL)

ssh_tunnel_create supports local, remote, and dynamic (SOCKS5) forwarding with no restrictions on destination hosts/ports. An agent could set up a SOCKS proxy and route traffic through any server, or expose internal services to external networks.

4. Unrestricted file transfers (HIGH)

ssh_upload, ssh_download, and ssh_sync have no path restrictions. An agent can download /etc/shadow, SSH keys, or any file — and upload backdoors to any location.

5. SQL injection bypass in ssh_db_query (MEDIUM)

The isSafeQuery() function uses keyword matching that's bypassable — SELECT LOAD_FILE('/etc/passwd') passes the check. MongoDB queries have no validation at all, allowing arbitrary JS execution.

Suggestions

1. Command allowlist/blocklist — at minimum block rm -rf, dd, mkfs, shutdown
2. Remove direct password parameters from sudo tools — don't let the agent handle credentials
3. Path restrictions for file transfers — block access to .ssh/, /etc/shadow, etc.
4. Tunnel destination allowlist — disable SOCKS by default
5. Approval gate for ssh_execute, ssh_execute_sudo, ssh_execute_group
6. Proper SQL parser instead of keyword matching for isSafeQuery()

Impressive feature set for the tool. These are hardening suggestions given the risk level of remote SSH access in agent workflows.

---

Found using AgentWard — open-source permission control plane for AI agents.

[bvisible]

Thanks for taking the time to audit this @Ratnaditya-J. I want to give a substantive response because I think the framing of the report misses an important point about what this MCP server is — but there are also two specific findings I do want to act on.

Threat model

mcp-ssh-manager is an SSH client surface for an LLM. When a user installs it and exposes it to Claude Code / OpenAI Codex, they are explicitly delegating SSH-level access to those agents. That access is the entire point of the tool. So the framing "37 tools give an agent unrestricted SSH access" is tautological — an SSH manager that filters rm, blocks SOCKS, denies arbitrary paths, and gates sudo behind approval prompts isn't an SSH manager anymore; it's a restricted shell on top of SSH, which already exists at the OS layer (rbash, sudoers rules, ForceCommand, ACLs, AppArmor profiles).

The permission gate belongs in two places, neither of which is this server:

1. In the agent host (Claude Code / Codex), which already prompts the user per tool call. Users who want stronger gating can configure allowedTools / disallowedTools and per-server approval rules. That's where "don't let the agent run ssh_execute_sudo without my explicit OK" lives.
2. On the remote SSH server, via sudoers (NOPASSWD only for allowed commands), restricted shells, jump-host policies, network ACLs. Those layers are battle-tested and apply uniformly to every SSH client — mcp-ssh-manager, OpenSSH ssh, Ansible, a human at a terminal.

Adding a command allowlist to this MCP would create a false sense of security: a user who installs it believing "rm -rf is blocked" still gets compromised the moment an agent runs bash -c 'rm -rf /' or python -c "import os; os.system('...')". There's no robust way to filter arbitrary shell from the client side, and pretending otherwise is worse than not pretending.

Findings #1 (unrestricted command exec), #2's first half (sudo escalation as a feature), #3 (SOCKS tunneling), and #4 (file transfers) are therefore working as intended. Closing them as wontfix is the honest answer.

What I am taking from this report

Two findings point at real, actionable smells — not threat-model conflations:

1. sudo -S via echo "$password" | sudo -S … (finding #2, technical half)
The password is visible in the process list on the remote host for the lifetime of the echo (and via /proc/<pid>/cmdline for the shell pipeline). On a shared server, any user can ps auxf it. This is a legit issue regardless of threat model — even users who want the agent to have sudo access don't want the password leaked to local accounts. → I'm opening a dedicated issue for this and will track the fix there.

2. isSafeQuery() keyword matching (finding #5)
SELECT LOAD_FILE('/etc/passwd') does bypass the check, and MongoDB has no validation. But: the tool is explicitly named ssh_db_query for SELECT statements, and any user who wants LOAD_FILE can just call ssh_execute with mysql -e. The "safety" of ssh_db_query is a convenience UX (don't run UPDATE/DELETE by accident), not a security boundary. I'll either rename / re-document it to reflect that, or drop the keyword check entirely and let the user be responsible — but I won't pretend a regex-based SQL parser is a security feature.

Closing this

I'm closing this aggregate report because (a) most of its findings are by-design behaviors of an SSH tool, and (b) the two actionable items will get focused tracking issues. Mixing real bugs with category-level concerns makes both harder to address.

Appreciate the time and the framing of "hardening, not bugs" — that part is fair. Looking forward to AgentWard's per-tool-call gating being usable from the agent side, which is genuinely where this problem should be solved.