Ansible
PassAudited by VirusTotal on May 12, 2026.
Overview
Type: OpenClaw Skill Name: ansible-skill Version: 0.1.0 The skill is designed for infrastructure automation using Ansible, which inherently involves high-privilege actions such as creating sudo users, managing SSH keys, configuring firewalls, and executing arbitrary commands on remote servers. While these capabilities are necessary for its stated purpose of server provisioning and configuration, they represent significant security risks if misused. The `SKILL.md` demonstrates retrieving secrets from OpenClaw's `.secrets` mechanism and passing them to Ansible, and the `playbooks/openclaw-vps.yml` creates a new user with passwordless sudo access and adds SSH keys. There is no clear evidence of intentional malicious behavior like data exfiltration or covert backdoors; in fact, the skill includes security hardening steps. However, due to the broad permissions and powerful execution capabilities, it is classified as suspicious.
Findings (0)
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.
A normal playbook run could change packages, SSH, firewall, users, and services across multiple servers, potentially locking users out or altering production systems.
The main playbook applies privileged roles to every host in the inventory. For Ansible this is expected capability, but as a reusable skill it is overbroad unless the user explicitly reviews the inventory and limits the run.
- name: Base configuration for all servers
hosts: all
become: yes
roles:
- role: common
- role: securityRequire explicit user approval before running playbooks, default to --check/--list-hosts, and require --limit or a user-provided inventory for any mutating run.
If the local SSH key exists and has access, the skill can operate on named remote servers with elevated privileges.
The bundled inventory contains concrete server IPs, a named user, a local SSH private key path, and a production group. This is high-impact delegated access rather than a neutral placeholder inventory.
plane:
ansible_host: 217.13.104.99
ansible_user: asdbot
ansible_ssh_private_key_file: ~/.ssh/id_ed25519_plane
...
production:
hosts:
plane:
vault:Remove real hosts and key paths from the distributed skill, require users to supply their own inventory, and clearly declare SSH credentials and sudo requirements.
A future package update or registry compromise could change what is installed on managed servers.
The OpenClaw role defaults to installing the latest package version. This is purpose-aligned for setup automation, but it reduces reproducibility and increases supply-chain exposure.
openclaw_version: "latest"
Pin Ansible collections, Node.js/OpenClaw versions, and package sources for production use; review external repositories before running.
Local users or later automation may see server details or act on stale cached information, depending on file permissions and log contents.
The configuration persists Ansible facts and logs in /tmp. These may include host details and task output, and stale cached facts can influence later runs.
fact_caching_connection = /tmp/ansible_facts fact_caching_timeout = 86400 log_path = /tmp/ansible.log
Store logs and fact caches in a restricted directory, disable logging for sensitive runs, and mark secret-handling tasks with no_log.
If enabled later, the OpenClaw gateway will keep running after the setup task and restart on failure.
The playbook creates a persistent systemd service definition for the OpenClaw gateway. The same artifact says it is not enabled automatically, so this is disclosed and purpose-aligned, but it is still persistent infrastructure.
dest: /etc/systemd/system/openclaw.service ... ExecStart=/usr/bin/openclaw gateway start --foreground Restart=on-failure
Enable the service only after reviewing its configuration, API keys, network exposure, and operating user.