ssh-agentd-control

• Outcome: Review
• Latest audit: Sep 11, 2026 · 3:33 AM UTC
• Version: 0.1.0

Overview

The skill is coherent for administering ssh-agentd, but it gives an agent privileged service-control, boot-persistence, and remote-command examples without enough scoping or confirmation guidance.

Install only if you intentionally manage this exact ssh-agentd setup. Before using the mutating commands, inspect ssh-agentd.service and the referenced binary/config ownership and permissions, keep the API bound to localhost unless needed, protect SSH_AGENTD_TOKEN, and require explicit approval before enabling, restarting, stopping, or invoking /run.

A.I.G

Vulnerability Patterns

• System Persistence: Installs backdoors, hooks, services, or scheduled tasks that survive the run
• 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
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (1)

T06 · System Persistence

Error

• Location: SKILL.md:27
• Finding: Privileged Systemd Service Persistence Without Verifiable Service Definition## Vulnerability Details **File Location**: `SKILL.md`, line 27 **Vulnerability Type**: `T06: System Persistence` **Risk Level**: High **Complete Code Snippet**: ```bash sudo systemctl daemon-reload sudo systemctl enable --now ssh-agentd.service sudo systemctl restart ssh-agentd.service sudo systemctl stop ssh-agentd.service ``` ### Technical Analysis The command `sudo systemctl enable --now ssh-agentd.service` performs two privileged operations: 1. It starts the service immediately. 2. It registers the service to start automatically on future boots. Persistence is related to the Skill's declared support for a systemd-resident SSH agent and persistent SSH sessions. However, enabling boot persistence is not necessary for routine API requests, health checks, session inspection, or one-time service execution. It therefore exceeds the minimum privileges required for those common operations unless the user explicitly requests automatic startup. The service unit, referenced executable, and configuration are not included in the audited project. The documentation instead references external resources such as `/home/krex/.openclaw/workspace-hermes/ssh-agentd/bin/ssh-agentd` and `/home/krex/.openclaw/ssh-agentd/hosts.yaml`. Consequently, this package cannot establish what executable systemd will launch, which user it will run as, or whether appropriate systemd sandboxing is configured. ### Attack Path 1. An attacker or another compromised process creates or modifies `ssh-agentd.service`, its referenced executable, or associated configuration outside this project. 2. An operator or AI agent follows the Skill instructions and authorizes the `sudo systemctl enable --now ssh-agentd.service` command. 3. systemd immediately launches the externally defined and unaudited service with the privileges configured by its unit. 4. The enable operation installs cross-session persistence, causing the same service to launch after subseque ...[truncated 857 chars]
• Remediation: ## Remediation Suggestions - Do not enable the service automatically as part of routine Skill use. Separate API operations, temporary service startup, and boot-persistence setup into distinct workflows. - Require explicit, informed user confirmation before executing `sudo systemctl enable`, clearly stating that it creates persistence across reboots. - Prefer `systemctl start ssh-agentd.service` without `enable` when only temporary operation is required. - Before startup or enablement, inspect the effective unit with `systemctl cat ssh-agentd.service` and `systemctl show ssh-agentd.service`. - Verify the referenced executable and configuration using trusted ownership, restrictive permissions, and a known-good checksum or signature. - Confirm that neither the unit nor its executable is writable by untrusted users. - Run the daemon as a dedicated unprivileged account, or use a per-user systemd service where system-wide privileges are unnecessary. - Harden the unit with appropriate controls such as `NoNewPrivileges=true`, `ProtectSystem=strict`, `ProtectHome=true`, `PrivateTmp=true`, restricted capabilities, and narrowly scoped filesystem access. - Keep the API bound to loopback unless remote exposure is explicitly required, and retain authentication for commands capable of remote execution. - Include the service unit or a verifiable unit template in the audited package so its executable path, service user, capabilities, and sandboxing can be reviewed.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Rogue Agent: Self-Modification, Session Persistence
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration

Findings (13)

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 87% confidence
• Finding: The skill invokes shell commands with privileged service management and API operations, but it declares no explicit tool scope or permissions boundary. That increases the chance the agent may overreach and execute impactful commands in contexts where the user only asked for general troubleshooting or information.

Vague Triggers

Medium

• Confidence: 89% confidence
• Finding: The activation text is broad enough to trigger on common troubleshooting phrases like metrics, session status, or startup behavior, which could invoke a skill capable of sudo service control and remote command execution. Overbroad routing is dangerous because it may cause high-impact operational actions to be suggested or performed in situations that only needed low-risk diagnostic help.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

## 快速检查

```bash
sudo systemctl is-enabled ssh-agentd.service
sudo systemctl is-active ssh-agentd.service
ss -ltnp | grep 18081
sudo systemctl status ssh-agentd.service --no-pager -l | sed -n '1,80p'

• Confidence: 70% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

## 快速检查

```bash
sudo systemctl is-enabled ssh-agentd.service
sudo systemctl is-active ssh-agentd.service
ss -ltnp | grep 18081
sudo systemctl status ssh-agentd.service --no-pager -l | sed -n '1,80p'

• Confidence: 70% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

## 快速检查

```bash
sudo systemctl is-enabled ssh-agentd.service
sudo systemctl is-active ssh-agentd.service
ss -ltnp | grep 18081
sudo systemctl status ssh-agentd.service --no-pager -l | sed -n '1,80p'

• Confidence: 70% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Session Persistence

Medium

• Category: Rogue Agent

Content

## 快速检查

```bash
sudo systemctl is-enabled ssh-agentd.service
sudo systemctl is-active ssh-agentd.service
ss -ltnp | grep 18081
sudo systemctl status ssh-agentd.service --no-pager -l | sed -n '1,80p'

• Confidence: 80% confidence
• Finding: Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Missing User Warnings

Medium

• Confidence: 90% confidence
• Finding: The examples show service enable/restart/stop and a remote command execution endpoint without prominent warnings that these actions can alter host state, affect availability, or execute commands on remote systems. In a skill meant for agent use, cookbook-style examples can be operationalized directly, making omission of safety gates materially risky.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

## 启停与自启

```bash
sudo systemctl daemon-reload
sudo systemctl enable --now ssh-agentd.service
sudo systemctl restart ssh-agentd.service
sudo systemctl stop ssh-agentd.service

• Confidence: 83% confidence
• Finding: `sudo systemctl daemon-reload` performs a privileged operational change and can apply altered unit definitions. In a skill lacking strict scoping and confirmation rules, including this as a ready-to-run example raises the risk of unintended privileged changes during routine troubleshooting.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

```bash
sudo systemctl daemon-reload
sudo systemctl enable --now ssh-agentd.service
sudo systemctl restart ssh-agentd.service
sudo systemctl stop ssh-agentd.service
```

• Confidence: 92% confidence
• Finding: `sudo systemctl enable --now ssh-agentd.service` both persists the service across reboots and starts it immediately, creating a durable privileged change. If triggered inappropriately, it can establish unwanted persistence and expose the local API service without sufficient review of configuration or access controls.

Session Persistence

Medium

• Category: Rogue Agent

Content

```bash
sudo systemctl daemon-reload
sudo systemctl enable --now ssh-agentd.service
sudo systemctl restart ssh-agentd.service
sudo systemctl stop ssh-agentd.service
```

• Confidence: 94% confidence
• Finding: This command explicitly enables the service at boot, which is a persistence mechanism. In a skill that also describes API access and remote execution, persistence materially increases risk because it makes the service continuously available and harder to notice if enabled without deliberate intent.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

```bash
sudo systemctl daemon-reload
sudo systemctl enable --now ssh-agentd.service
sudo systemctl restart ssh-agentd.service
sudo systemctl stop ssh-agentd.service
```

• Confidence: 86% confidence
• Finding: `sudo systemctl restart ssh-agentd.service` is a privileged, state-changing action that can disrupt active sessions or alter service behavior after config changes. In an auto-invoked skill, restart examples without safety gates increase the chance of accidental service interruption.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

sudo systemctl daemon-reload
sudo systemctl enable --now ssh-agentd.service
sudo systemctl restart ssh-agentd.service
sudo systemctl stop ssh-agentd.service
```

## API 调用要点

• Confidence: 84% confidence
• Finding: `sudo systemctl stop ssh-agentd.service` can immediately terminate service availability and any dependent workflows. Including it as an unguarded example is risky because a troubleshooting flow could unnecessarily turn into a denial-of-service against the managed agent.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The script reads a credential-like value from SSH_AGENTD_TOKEN and includes it as an Authorization header in outgoing HTTP requests. There is no confirmation prompt, logging, comment, or docstring warning the user that authentication data may be sent to the target endpoint.

Static analysis

No suspicious patterns detected.