Ssh Remote Sanitized

• Outcome: Review
• Latest audit: Sep 12, 2026 · 1:34 AM UTC
• Version: 1.0.0

Overview

This SSH administration skill is coherent, but it gives broad remote control while missing important safeguards around credentials, host identity, command construction, destructive actions, and target selection.

Review this skill carefully before installing, especially for production servers. Use only least-privilege SSH accounts and dedicated keys, avoid storing passwords or key passphrases in the JSON config, verify server host keys out of band, and do not run destructive or sudo-backed operations unless you have separately validated the inputs and target host.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (9)

T09 · Insecure Skill Coding Practices

Error

• Location: src/service.js:46
• Finding: Privileged Remote Command Injection Through Service Names<![CDATA[ ## Vulnerability Details **File Location**: `src/service.js:46-102` **Vulnerability Type**: OS command injection in privileged remote service-management commands **Risk Level**: Critical ### Vulnerable Code ```js const result = await execSSH(serverName, `sudo systemctl start ${serviceName}`); ``` The same unsafe construction is used for `stop`, `restart`, `reload`, `enable`, and `disable` operations. ### Technical Analysis `serviceName` is inserted directly into a shell command sent through SSH. No validation, argument quoting, or metacharacter rejection is performed. Because the remote SSH server interprets the command through a shell, a value containing separators such as `;`, `&&`, command substitution, redirection, or newlines can escape the intended `systemctl` argument. The command also invokes `sudo`, so the injected command may run with root privileges when the connected account has non-interactive sudo authorization. The `systemctl enable` behavior is part of the declared service-management functionality and is not covert persistence by itself. The vulnerability is that arbitrary shell syntax can be injected into that privileged operation. ### Attack Path 1. An attacker or untrusted caller supplies a crafted service name, such as `nginx; id`. 2. The Skill constructs: ```sh sudo systemctl start nginx; id ``` 3. The remote shell starts the service and then executes the injected command. 4. If a suitable sudo rule is available, an attacker can substitute a payload that modifies privileged files, creates users, installs services, or establishes persistence. ### Impact Assessment Successful exploitation provides arbitrary command execution on the selected remote server under the SSH account. Depending on sudo configuration, it can provide root-level control. Potential consequences include: - Starting, stopping, or disabling critical services. - Installing or enabling persistent system services. - Modifying privileged configu ...[truncated 153 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Do not concatenate untrusted values into shell command strings. - Validate service names against a restrictive allowlist, for example: ```js if (!/^[A-Za-z0-9_.@-]+$/.test(serviceName)) { throw new Error('Invalid service name'); } ``` - Validate `state` against an explicit list such as `all`, `active`, `inactive`, and `failed`. - Use a well-reviewed POSIX shell-argument escaping function if a shell cannot be avoided. - Require explicit user confirmation for destructive or persistent actions such as `stop`, `disable`, and `enable`. - Configure sudo so the SSH account can invoke only the required `systemctl` subcommands and approved service units. - Record an audit event containing the selected host, service, action, and requesting identity before execution. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: src/log.js:19
• Finding: Privileged Command Injection in Log Cleanup and Log Query Functions<![CDATA[ ## Vulnerability Details **File Location**: `src/log.js:19-227` **Vulnerability Type**: OS command injection, including injection into a destructive sudo operation **Risk Level**: Critical ### Vulnerable Code The most severe sink is the privileged deletion operation: ```sh sudo find /var/log -type f -name "*.log" -mtime +${days} -delete && ``` Other affected constructions include: ```js const result = await execSSH(serverName, `docker logs --tail ${lines} ${containerName}`); ``` ```js const result = await execSSH(serverName, `grep -i "${pattern}" ${logFile} | tail -n ${lines}`); ``` ```js const result = await execSSH(serverName, `tail -f ${logFile}`, { pty: true }); ``` ### Technical Analysis Values including `days`, `lines`, `containerName`, `pattern`, `logFile`, journal unit, priority, and date filters are embedded directly into remote shell commands. They are not subjected to numeric type checks, range limits, safe path validation, or shell quoting. The `cleanupOldLogs` sink is especially dangerous because it combines attacker-controlled syntax with `sudo find` and file deletion. A crafted value can alter the command structure or append another shell command. Quoting `pattern` with double quotes is insufficient because double-quoted shell strings still process command substitutions and can be terminated using an embedded quote. ### Attack Path 1. A caller invokes log cleanup with a nonnumeric `days` value containing shell syntax. 2. The value is inserted after `-mtime +`. 3. The remote shell parses the injected separators or substitutions. 4. The injected payload runs in the same administrative session. 5. Similar exploitation is possible through crafted log paths, search patterns, container names, or journal options. ### Impact Assessment Exploitation can result in: - Arbitrary remote command execution. - Deletion or alteration of system and application logs. - Destruction of forensic evidence. - Disclosure of arbitrary files readab ...[truncated 192 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Convert numeric inputs using strict parsing and enforce safe ranges: ```js if (!Number.isInteger(days) || days < 1 || days > 3650) { throw new Error('Invalid retention period'); } ``` - Apply similar limits to line counts. - Restrict container and systemd unit names to explicit safe character sets. - Canonicalize and allowlist log paths under approved directories such as `/var/log`. - Do not interpolate search expressions into shell commands. Transfer them through a safely quoted argument or perform filtering in JavaScript. - Separate privileged cleanup from general log-reading capabilities. - Require confirmation before deletion and support a dry-run mode that lists affected files. - Use a narrowly scoped privileged helper instead of granting broad sudo access to shell-composed commands. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: src/upload.js:51
• Finding: Command Injection Through Upload Destinations and Preset Filenames<![CDATA[ ## Vulnerability Details **File Location**: `src/upload.js:51-225` **Vulnerability Type**: OS command injection in remote directory, permission, and ownership operations **Risk Level**: Critical ### Vulnerable Code ```js conn.exec(`mkdir -p ${remoteDir}`, (err) => { ``` ```js conn.exec(`chmod ${settings.permissions} ${remotePath}`, (err) => { ``` ```js conn.exec(`sudo chown ${settings.owner} ${remotePath}`, (err) => { ``` ### Technical Analysis Remote directories and paths are inserted directly into shell commands without quoting or validation. In `uploadWithPreset`, `fileName` is used to construct `remotePath`, which is subsequently passed to both `chmod` and `sudo chown`. Although the permissions and owner fields come from fixed presets, the path remains attacker-controlled. Shell metacharacters in the path can terminate the intended command and introduce another command. The `chown` sink can expose the injected payload to a sudo-enabled execution context. SFTP operations do not require shell parsing and are safer, but the implementation switches back to shell commands for directory creation and metadata changes. ### Attack Path 1. A caller supplies a remote directory or preset filename containing shell separators. 2. The Skill uploads the file or attempts to create its directory. 3. It constructs a command such as: ```sh sudo chown www-data:www-data /var/www/html/name; attacker-command ``` 4. The remote shell executes the appended payload. 5. If sudo authorization permits the operation broadly, the payload may obtain privileged impact. ### Impact Assessment An attacker can execute commands under the remote SSH identity and may obtain root-level effects through the sudo operation. Consequences include: - Modification of privileged files. - Deployment of executable payloads. - Creation or replacement of service configuration. - Ownership changes affecting application integrity. - Persistent compromise of managed servers. ]]>
• Remediation: <![CDATA[ ## Remediation Suggestions - Use SFTP `mkdir`, `chmod`, and related APIs instead of executing shell commands. - Reject NUL characters, control characters, newlines, and shell metacharacters in remote path components. - Normalize remote paths and enforce containment under the selected preset base directory. - Reject absolute filenames and traversal components such as `..`. - If ownership changes require privilege, expose a narrowly scoped helper that accepts validated path identifiers rather than shell text. - Apply least-privilege sudo rules limited to approved directories and owners. - Avoid following local symbolic links during recursive upload unless the caller explicitly enables that behavior. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: src/index.js:47
• Finding: SSH Connections Do Not Verify Remote Host Identity<![CDATA[ ## Vulnerability Details **File Location**: `src/index.js:47-81` **Vulnerability Type**: Missing SSH host-key verification **Risk Level**: High ### Vulnerable Code ```js const connectionConfig = { host: config.host, port: config.port || 22, username: config.username, readyTimeout: 30000, keepaliveInterval: 10000 }; conn.connect(connectionConfig); ``` ### Technical Analysis The SSH connection configuration does not define a trusted host-key fingerprint or a `hostVerifier`. As a result, the client has no configured mechanism to verify that the responding SSH server is the intended host. SSH encryption alone does not prevent impersonation when the server identity is not authenticated. An attacker able to redirect DNS, routing, or local network traffic can present an attacker-controlled SSH server. ### Attack Path 1. The attacker gains a position capable of redirecting traffic to the configured SSH hostname or IP address. 2. The attacker presents an SSH server with an attacker-controlled host key. 3. The Skill connects without comparing the key against a trusted fingerprint. 4. Password credentials may be disclosed to the impersonating server. 5. Administrative commands and uploaded files are sent to the attacker-controlled endpoint, while downloaded content can be substituted. ### Impact Assessment The vulnerability can compromise the confidentiality and integrity of: - SSH passwords and authentication data. - Administrative commands. - Uploaded application files and configuration. - Downloaded logs, backups, or configuration. - Operational decisions based on substituted command output. The attack affects any configured server whose network path or name resolution can be manipulated. ]]>
• Remediation: <![CDATA[ ## Remediation Suggestions - Require a SHA-256 host-key fingerprint for every configured server. - Implement `hostVerifier` and compare keys using constant-time logic where practical. - Support a managed `known_hosts` file and reject unknown or changed keys by default. - Do not provide a silent “accept any key” mode for production use. - Clearly report fingerprint mismatches without falling back to another server. - Protect host-key configuration with the same permissions as SSH credential configuration. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: src/exec.js:84
• Finding: Unsafe Remote Script Staging Uses a Predictable Shared Temporary Path<![CDATA[ ## Vulnerability Details **File Location**: `src/exec.js:84-91` **Vulnerability Type**: Predictable temporary file and unsafe heredoc construction **Risk Level**: High ### Vulnerable Code ```js async function execScript(serverName, script) { const tempFile = `/tmp/ssh_remote_${Date.now()}.sh`; await execSSH(serverName, `cat > ${tempFile} << 'EOF'\n${script}\nEOF`); await execSSH(serverName, `chmod +x ${tempFile}`); const result = await execSSH(serverName, `bash ${tempFile}`); await execSSH(serverName, `rm -f ${tempFile}`); ``` ### Technical Analysis The temporary filename is derived only from the current timestamp and is placed in the globally shared `/tmp` directory. Another user on the remote system may predict or race the path, including by creating a symbolic link before the file is written. The script is transferred through a shell heredoc with a fixed `EOF` delimiter. Script text containing a matching delimiter line can terminate the heredoc early and alter the surrounding shell command. Arbitrary script execution is a declared feature, but this construction still undermines reliable command boundaries and safe temporary-file handling. Cleanup is not protected by `finally`, so a failure during permission changes or execution can leave the script behind. ### Attack Path 1. A local attacker on the remote server predicts the timestamp-based path. 2. The attacker creates a symlink or conflicting file at that location. 3. The Skill redirects heredoc output to the attacker-selected path. 4. The Skill applies executable permissions and runs the resulting path. 5. Alternatively, crafted script text can terminate the fixed heredoc and change how the staging command is parsed. ### Impact Assessment The impact is limited to the privileges of the configured SSH account unless that account is privileged. Possible outcomes include: - Overwriting a file selected through a symlink race. - Executing attacker-controlled content. - Leaving sen ...[truncated 169 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Create a private remote temporary directory using `mktemp -d` with mode `0700`. - Generate a cryptographically random filename rather than using `Date.now()`. - Transfer script bytes through SFTP instead of a shell heredoc. - Open temporary files exclusively and reject symbolic links. - Use mode `0700` or `0600` as appropriate. - Place deletion in a `finally` block so cleanup occurs after failures. - Where possible, run scripts through standard input rather than writing executable files. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: src/connect.js:82
• Finding: SSH Passwords and Key Passphrases Are Stored in Plaintext Without Enforced Permissions<![CDATA[ ## Vulnerability Details **File Location**: `src/connect.js:82-153` **Vulnerability Type**: Insecure sensitive credential storage **Risk Level**: High ### Vulnerable Code ```js config.servers.push(serverConfig); fs.writeFileSync(configPath, JSON.stringify(config, null, 2)); ``` ```js data.servers[index] = { ...data.servers[index], ...config }; fs.writeFileSync(configPath, JSON.stringify(data, null, 2)); ``` ### Technical Analysis `serverConfig` can contain a password or private-key passphrase. The complete object is serialized directly to `servers.json`. The write operations do not specify mode `0600`, do not verify the permissions of an existing file, and do not perform an atomic replacement. Effective permissions therefore depend on the process umask or prior file state. Documentation also provides plaintext password examples, encouraging this storage model. Private-key path references are expected for SSH authentication, and the runtime reads rather than overwrites the key itself. The issue is the plaintext persistence of password and passphrase values in the Skill configuration. ### Attack Path 1. A user adds or updates a server using password or passphrase authentication. 2. The Skill writes the credential into `servers.json`. 3. Another local user, compromised process, backup system, or accidental repository inclusion exposes the file. 4. The recovered credential is reused to access the managed server. ### Impact Assessment Credential disclosure can provide direct SSH access to configured servers. The resulting scope depends on the compromised account and may include: - Remote command execution. - Access to production files and secrets. - Privileged sudo operations. - Lateral movement to additional infrastructure. - Long-term access until the credentials are rotated. ]]>
• Remediation: <![CDATA[ ## Remediation Suggestions - Prefer SSH agents, hardware-backed keys, or an operating-system secret store. - Do not persist private-key passphrases or SSH passwords in the general JSON configuration. - Create the configuration directory with mode `0700`. - If sensitive file storage is unavoidable, create the file atomically with mode `0600`. - Verify and repair permissions before every read and write. - Separate nonsecret server metadata from secret values. - Redact credentials from errors, logs, backups, and returned objects. - Update documentation to recommend agent-based or secret-store authentication. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: src/download.js:281
• Finding: Preset Downloads Permit Local Path Traversal and Arbitrary File Replacement<![CDATA[ ## Vulnerability Details **File Location**: `src/download.js:281-294` **Vulnerability Type**: Path traversal and unrestricted local file write **Risk Level**: High ### Vulnerable Code ```js async function downloadWithPreset(serverName, fileName, preset) { const settings = downloadPresets[preset]; if (!settings) { throw new Error(`Unknown preset: ${preset}`); } const remotePath = `${settings.remoteBase}/${fileName}`; const localPath = path.join(settings.localBase, fileName); return download(serverName, remotePath, localPath); } ``` The underlying download writes directly to the supplied destination: ```js sftp.fastGet(remotePath, localPath, (err) => { ``` ### Technical Analysis `fileName` is joined to a preset local base without rejecting traversal components such as `..`. A sufficiently crafted relative path can escape the intended download directory. The generic download operation also accepts unrestricted local destinations and overwrites existing files according to the underlying file-opening behavior. No dedicated storage root, overwrite confirmation, symbolic-link defense, or canonical containment check is present. ### Attack Path 1. An attacker supplies a preset filename containing repeated `../` components. 2. `path.join` normalizes the resulting path outside the preset directory. 3. The Skill downloads attacker-selected remote content to that local path. 4. If the Agent process can write the target, the existing file is replaced. 5. A strategically selected configuration or executable file can affect later Agent or system behavior. ### Impact Assessment The attacker can overwrite files writable by the local Agent process. Potential impact includes: - Corruption of Agent configuration or state. - Replacement of scripts or application assets. - Creation of persistent behavior if a startup-loaded file is writable. - Denial of service. - Local code execution when overwritten content is later executed or loaded. ]]>
• Remediation: <![CDATA[ ## Remediation Suggestions - Resolve all download targets against a dedicated download root. - Verify containment after normalization: ```js const root = path.resolve(settings.localBase); const destination = path.resolve(root, fileName); if (destination !== root && !destination.startsWith(root + path.sep)) { throw new Error('Download path escapes the approved directory'); } ``` - Reject absolute paths, `..` components, NUL characters, and unexpected separators. - Refuse to overwrite existing files unless the user explicitly confirms. - Use exclusive file creation where practical. - Detect and reject symbolic links in parent components. - Apply equivalent containment checks to remote preset paths. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: src/index.js:107
• Finding: Unknown Server Names Silently Fall Back to the First Configured Host<![CDATA[ ## Vulnerability Details **File Location**: `src/index.js:107-113` **Vulnerability Type**: Unsafe target selection and fail-open configuration behavior **Risk Level**: Medium ### Vulnerable Code ```js const servers = getSSHConfig(); const server = servers.find(s => s.name === serverName) || servers[0]; if (!server) { throw new Error(`Server configuration not found: ${serverName}`); } ``` ### Technical Analysis When `serverName` does not match a configured alias, the implementation selects `servers[0]` instead of failing. The error condition only applies when no servers exist at all. This behavior can redirect a command, upload, service restart, security hardening action, or destructive log operation to an unintended system. The problem is particularly serious when the first entry is a production or privileged host. ### Attack Path 1. A user or attacker supplies a misspelled or nonexistent server alias. 2. Exact lookup fails. 3. The expression falls back to the first configured server. 4. The requested operation executes against that server without an explicit target-selection warning. ### Impact Assessment The vulnerability does not independently increase OS privileges, but it can apply existing SSH privileges to the wrong host. Consequences include: - Restarting or disabling services on production systems. - Uploading files to an unintended server. - Applying firewall or SSH configuration changes to the wrong host. - Deleting logs or executing arbitrary commands against an unintended target. ]]>
• Remediation: <![CDATA[ ## Remediation Suggestions - Remove the `|| servers[0]` fallback. - Require an exact and unique server-name match. - Validate that every configured server has a nonempty, unique name. - Include the resolved hostname and username in a confirmation prompt before destructive or privileged actions. - Add tests proving that unknown aliases fail without opening a connection. ]]>

T08 · Insecure Dependencies

Warning

• Location: skill.json:15
• Finding: Dependency Installation Is Not Reproducible or Integrity-Locked<![CDATA[ ## Vulnerability Details **File Location**: `skill.json:15-17` **Vulnerability Type**: Unpinned dependency resolution without a committed lockfile **Risk Level**: Medium ### Vulnerable Code ```json "dependencies": { "ssh2": "^1.15.0" } ``` ### Technical Analysis The dependency uses a caret range, allowing future compatible releases to be selected. No lockfile or integrity record was present in the audited project structure. The documentation instructs users to run `npm install`, but installations at different times can therefore resolve different package versions. This expands supply-chain exposure and prevents exact reproduction of the reviewed dependency graph. No evidence was found that `ssh2` itself is malicious. The issue is the unsafe and non-reproducible dependency-management process. ### Attack Path 1. A user installs the Skill at a later time. 2. The package manager resolves a newer version allowed by the caret range. 3. If that version or its transitive dependency chain is compromised, unexpected code runs during installation or Skill execution. 4. The absence of a reviewed lockfile makes the resolved change less visible. ### Impact Assessment A compromised dependency executes with the privileges of the local Agent process. It could potentially access: - SSH configuration and plaintext credentials. - Private keys readable by the process. - Downloaded files and local Agent state. - Network access to configured remote hosts. - Commands and data passing through SSH sessions. ]]>
• Remediation: <![CDATA[ ## Remediation Suggestions - Provide a standard `package.json` with reviewed package metadata. - Commit the generated lockfile and its integrity hashes. - Use `npm ci` for deployment rather than unconstrained `npm install`. - Pin reviewed dependency versions or use controlled automated update tooling. - Run dependency vulnerability and provenance checks in CI. - Review lockfile changes before release. - Avoid install scripts unless they are required and explicitly reviewed. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands

Findings (101)

Credential Access

High

• Category: Privilege Escalation

Content

"host": "YOUR_SERVER_IP",
      "port": 22,
      "username": "YOUR_USERNAME",
      "privateKeyPath": "~/.ssh/id_rsa"
    }
  ]
}

• Confidence: 90% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

"host": "YOUR_SERVER_IP",
      "port": 22,
      "username": "YOUR_USERNAME",
      "privateKeyPath": "~/.ssh/id_rsa"
    }
  ]
}

• Confidence: 90% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

"host": "YOUR_SERVER_IP",
      "port": 22,
      "username": "YOUR_USERNAME",
      "privateKeyPath": "~/.ssh/id_rsa"
    }
  ]
}

• Confidence: 90% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

"host": "YOUR_SERVER_IP",
      "port": 22,
      "username": "YOUR_USERNAME",
      "privateKeyPath": "~/.ssh/id_rsa"
    }
  ]
}

• Confidence: 90% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

"host": "YOUR_SERVER_IP",
      "port": 22,
      "username": "YOUR_USERNAME",
      "privateKeyPath": "~/.ssh/id_rsa"
    }
  ]
}

• Confidence: 90% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

"port": 22,
      "username": "SSH 用户名",
      "password": "SSH 密码（或使用私钥）",
      "privateKeyPath": "~/.ssh/id_rsa",
      "passphrase": "私钥密码（如有）"
    }
  ]

• Confidence: 90% confidence
• Finding: The configuration example explicitly includes plaintext fields for 'password' and 'passphrase' alongside a private key path, normalizing storage of sensitive secrets in a local JSON config. If users follow this pattern, credentials may be left unencrypted on disk, committed to repositories, or exposed to other local processes and backups.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

1. **凭证安全**：妥善保管 SSH 密码和私钥，不要提交到代码仓库
2. **权限控制**：确保 SSH 用户有足够权限
3. **连接池**：避免创建过多并发连接
4. **命令安全**：避免执行危险命令（如 `rm -rf /`）
5. **生产环境**：生产环境操作前请备份

---

• Confidence: 90% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

1. **凭证安全**：妥善保管 SSH 密码和私钥，不要提交到代码仓库
2. **权限控制**：确保 SSH 用户有足够权限
3. **连接池**：避免创建过多并发连接
4. **命令安全**：避免执行危险命令（如 `rm -rf /`）
5. **生产环境**：生产环境操作前请备份

---

• Confidence: 85% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

1. **凭证安全**:妥善保管 SSH 密码和私钥,不要提交到代码仓库
2. **权限控制**:确保 SSH 用户有足够权限
3. **连接池**:避免创建过多并发连接
4. **命令安全**:避免执行危险命令(如 `rm -rf /`)
5. **生产环境**:生产环境操作前请备份

---

• Confidence: 85% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 95% confidence
• Finding: 代码与描述在核心方向上基本一致，确实是一个 SSH 远程管理工具，并支持多服务器配置、连接复用、命令执行和文件传输。但描述声称支持系统监控、服务管理、日志分析、安全检查等更高层运维能力，而给出的代码中并未实现这些具体功能；仅提供了通用远程命令执行能力，理论上可被上层调用来完成这些任务，但这些能力并不是当前代码块直接实现的。因此描述相对代码存在一定夸大，属于能力声明与实际实现不完全一致。

Credential Access

High

• Category: Privilege Escalation

Content

"host": "YOUR_SERVER_IP",
      "port": 22,
      "username": "YOUR_USERNAME",
      "privateKeyPath": "~/.ssh/id_rsa"
    }
  ]
}

• Confidence: 90% confidence
• Finding: The documentation instructs users to reference a default private SSH key path (`~/.ssh/id_rsa`), which normalizes direct use of sensitive credentials by the skill. In a remote-management tool, encouraging broad access to a default private key can increase the blast radius of compromise, accidental disclosure, or misuse of highly privileged credentials.

Credential Access

High

• Category: Privilege Escalation

Content

"host": "192.168.1.100",
      "port": 22,
      "username": "root",
      "privateKeyPath": "/root/.ssh/id_rsa"
    },
    {
      "name": "staging",

• Confidence: 90% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

ssh 执行 production ls -la /path       # 列出文件
ssh 执行 production cat /path/file     # 查看文件
ssh 执行 production tail -f /path/log  # 实时日志
ssh 执行 production rm /path/file      # 删除文件
```

---

• Confidence: 88% confidence
• Finding: The documentation explicitly includes a destructive remote command example, rm /path/file, through a generic SSH execution interface. In an agent skill that can forward natural-language requests into remote shell actions, showcasing deletion without safeguards materially increases the risk of accidental or unauthorized data loss.

Description-Behavior Mismatch

High

• Confidence: 98% confidence
• Finding: cleanupOldLogs performs remote deletion of files under /var/log using sudo, which exceeds the expected semantics of a log viewing/analysis helper. In an SSH administration skill, this is especially dangerous because an upstream agent may call it automatically, causing loss of forensic evidence, operational visibility, or compliance-relevant logs on production systems.

Missing User Warnings

High

• Confidence: 98% confidence
• Finding: The code issues a destructive sudo delete command over SSH without any confirmation, preview, or safety interlock. In a remote operations skill, lack of a confirmation step materially increases the risk of accidental or automated execution against the wrong host, deleting logs needed for debugging, auditing, or incident response.

Chaining Abuse

High

• Category: Tool Misuse

Content

echo "4. 检查允许的用户:" &&
    grep -i "AllowUsers" /etc/ssh/sshd_config || echo "未限制用户" &&
    echo "" &&
    echo "5. 检查失败的登录尝试:" &&
    sudo lastb | head -10
  `);

• Confidence: 75% confidence
• Finding: Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.

Chaining Abuse

High

• Category: Tool Misuse

Content

echo "4. 检查允许的用户:" &&
    grep -i "AllowUsers" /etc/ssh/sshd_config || echo "未限制用户" &&
    echo "" &&
    echo "5. 检查失败的登录尝试:" &&
    sudo lastb | head -10
  `);

• Confidence: 75% confidence
• Finding: Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.

Chaining Abuse

High

• Category: Tool Misuse

Content

echo "4. 检查允许的用户:" &&
    grep -i "AllowUsers" /etc/ssh/sshd_config || echo "未限制用户" &&
    echo "" &&
    echo "5. 检查失败的登录尝试:" &&
    sudo lastb | head -10
  `);

• Confidence: 75% confidence
• Finding: Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.

Chaining Abuse

High

• Category: Tool Misuse

Content

echo "4. 检查允许的用户:" &&
    grep -i "AllowUsers" /etc/ssh/sshd_config || echo "未限制用户" &&
    echo "" &&
    echo "5. 检查失败的登录尝试:" &&
    sudo lastb | head -10
  `);

• Confidence: 75% confidence
• Finding: Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.

Chaining Abuse

High

• Category: Tool Misuse

Content

echo "4. 检查允许的用户:" &&
    grep -i "AllowUsers" /etc/ssh/sshd_config || echo "未限制用户" &&
    echo "" &&
    echo "5. 检查失败的登录尝试:" &&
    sudo lastb | head -10
  `);

• Confidence: 75% confidence
• Finding: Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.

Chaining Abuse

High

• Category: Tool Misuse

Content

echo "4. 检查允许的用户:" &&
    grep -i "AllowUsers" /etc/ssh/sshd_config || echo "未限制用户" &&
    echo "" &&
    echo "5. 检查失败的登录尝试:" &&
    sudo lastb | head -10
  `);

• Confidence: 75% confidence
• Finding: Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.

Chaining Abuse

High

• Category: Tool Misuse

Content

echo "4. 检查允许的用户:" &&
    grep -i "AllowUsers" /etc/ssh/sshd_config || echo "未限制用户" &&
    echo "" &&
    echo "5. 检查失败的登录尝试:" &&
    sudo lastb | head -10
  `);

• Confidence: 75% confidence
• Finding: Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.

Chaining Abuse

High

• Category: Tool Misuse

Content

echo "4. 检查允许的用户:" &&
    grep -i "AllowUsers" /etc/ssh/sshd_config || echo "未限制用户" &&
    echo "" &&
    echo "5. 检查失败的登录尝试:" &&
    sudo lastb | head -10
  `);

• Confidence: 75% confidence
• Finding: Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.

Chaining Abuse

High

• Category: Tool Misuse

Content

echo "4. 检查允许的用户:" &&
    grep -i "AllowUsers" /etc/ssh/sshd_config || echo "未限制用户" &&
    echo "" &&
    echo "5. 检查失败的登录尝试:" &&
    sudo lastb | head -10
  `);

• Confidence: 75% confidence
• Finding: Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.

Chaining Abuse

High

• Category: Tool Misuse

Content

echo "4. 检查允许的用户:" &&
    grep -i "AllowUsers" /etc/ssh/sshd_config || echo "未限制用户" &&
    echo "" &&
    echo "5. 检查失败的登录尝试:" &&
    sudo lastb | head -10
  `);

• Confidence: 75% confidence
• Finding: Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.

Static analysis

No suspicious patterns detected.