Ssh Batch Manager
WarnAudited by ClawScan on May 18, 2026.
Overview
This skill is purpose-aligned for SSH key management, but it can change access on many servers, stores SSH credentials, and auto-starts a persistent Web UI service with some unsafe defaults.
Install only if you intentionally want this skill to manage SSH access across your servers. Before enabling it, review the server list, use least-privilege accounts where possible, protect the credential JSON and encryption key, require confirmation for both enable and disable operations, and either disable the Web UI service or bind it strictly to localhost.
Findings (6)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
An agent or user flow could remove SSH access from many servers, potentially locking users out or disrupting administration.
The skill explicitly gates enable operations, but also exposes a bulk disable operation that removes keys from all configured servers without an equally explicit confirmation requirement.
**Before executing ANY enable operation ... MUST obtain explicit user confirmation** ... `disable-all` | Remove public key from all servers
Require explicit confirmation for every high-impact operation, including disable-all and single-server disable, and show the exact server list before execution.
A network attacker or misdirected hostname could receive credentials or have keys installed on the wrong host.
The SSH automation disables host-key verification while using passwords and key-management commands, which weakens server identity checks.
env['SSHPASS'] = password ... '-o', 'StrictHostKeyChecking=no', '-o', 'UserKnownHostsFile=/dev/null'
Do not disable SSH host-key checking by default; pin or verify known hosts and require an explicit user override for first-time or changed host keys.
Compromise or misuse of the skill, its config file, or its encryption key could grant access to many configured servers.
The skill stores and uses SSH server credentials, including examples for root access, even though the registry declares no primary credential or required config path.
**Location**: `~/.openclaw/credentials/ssh-batch.json` ... "user": "root" ... "password": "AES256:encrypted_password_here"
Treat this as a privileged SSH credential manager: use least-privilege accounts where possible, tightly restrict file permissions, keep the encryption key separate/protected, and ensure the registry declares the credential/config requirement.
Users or installers may not realize the skill expects package installation and a privileged setup script that changes the host environment.
The skill metadata describes package installation and a post-install script even though the supplied install spec says there is no install spec, creating an install-behavior mismatch.
"install": [ ... { "kind": "pip", "package": "cryptography" } ... { "kind": "apt", "package": "sshpass" } ... { "kind": "script", "script": "post-install.sh" } ]Align the registry install spec with the skill metadata, and make privileged post-install behavior explicit, opt-in, and reviewable.
A long-running SSH management UI can remain active after installation and increase the local attack surface.
The post-install script creates a systemd service, enables it at boot, and starts it immediately, causing the skill's Web UI to persist beyond the current task.
sudo tee "$SERVICE_FILE" ... ExecStart=/usr/bin/python3 ${SKILL_DIR}/serve-ui.py ... sudo systemctl enable ${SERVICE_NAME} ... sudo systemctl start ${SERVICE_NAME}Make auto-start optional, document how to disable/remove the service, and prefer manual start unless the user explicitly opts into persistence.
If the machine is reachable on the network, other hosts may be able to access the Web UI files and management surface.
Binding to an empty host listens on all network interfaces, not just localhost, while the Web UI is presented as a local management interface.
with socketserver.TCPServer(("", PORT), Handler) as httpd:Bind the service to 127.0.0.1 by default, add authentication if it must be network-accessible, and ensure firewall rules block unintended access.