Is botond-rackhost/ansible-skill safe?
https://github.com/openclaw/skills/tree/main/skills/botond-rackhost/ansible-skill
This Ansible skill is a legitimate infrastructure automation toolkit for the skill author's personal OpenClaw VPS deployment. It contains no prompt injection, no executable install hooks, and had a clean installation with no unexpected network activity. However, the pre-populated inventory hardcodes three real external IP addresses with matching SSH key file references, and the 'Integration with OpenClaw Agent' section provides copy-paste exec commands targeting these external servers — creating meaningful risk that a naive agent will SSH to someone else's infrastructure using local keys.
Category Scores
Findings (9)
HIGH Hardcoded external IP addresses in inventory with live SSH key references -28 ▶
inventory/hosts.yml contains three real VPS IP addresses (217.13.104.99, 217.13.104.231) with ssh_private_key_file pointing to ~/.ssh/id_ed25519_plane. SKILL.md repeats these plus 217.13.104.208. Any agent following the Quick Start or Integration examples will attempt SSH connections to these external servers using the agent machine's local keys.
HIGH Integration section provides agent-ready exec commands targeting external servers -30 ▶
The 'Integration with OpenClaw Agent' section of SKILL.md provides copy-paste exec commands that reference the hardcoded inventory. An agent reading this skill will find explicit instructions to run playbooks against 217.13.104.208 (eva). This functions as a ready-made social engineering template.
MEDIUM Apparent real plaintext password in vault documentation example -12 ▶
The vault file structure example contains what appears to be a real password rather than a placeholder: vault_eva_password: 'y8UGHR1qH'. While presented as documentation, this credential could be valid and exposed.
MEDIUM NodeSource GPG key fetched via curl pipe to gpg at runtime -12 ▶
roles/nodejs/tasks/main.yml fetches a remote GPG key via curl and pipes it directly to gpg for dearmoring. This pattern downloads and processes remote cryptographic material at playbook execution time, creating a supply-chain dependency.
MEDIUM ansible.cfg disables SSH host key checking globally -10 ▶
The bundled ansible.cfg sets host_key_checking = False, removing MITM protection for all playbook runs. Combined with the external IP inventory, this means an agent running playbooks provides no verification that it is connecting to the intended server.
MEDIUM openclaw npm package installed at 'latest' with no version pin -10 ▶
The openclaw role defaults to openclaw_version: 'latest', installing whatever the current npm registry version is. No hash pinning or version constraint is enforced, creating a supply-chain risk if the openclaw npm package is ever compromised.
LOW Canary credential files accessed post-install (likely monitor artifact) -15 ▶
Auditd records show .env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, and gcloud credentials were opened and accessed at audit(1771934477.284) after install completed. Timing and batch pattern suggest this is the oathe monitoring system performing post-install integrity verification rather than skill-originated access.
LOW External resource URLs embedded in SKILL.md -12 ▶
SKILL.md contains links to docs.ansible.com, galaxy.ansible.com, and GitHub. These are documentation references only, not agent fetch instructions, but they widen the attack surface if an agent follows external links.
INFO Clean install — only GitHub contacted during clone -10 ▶
Network monitoring confirmed no unexpected outbound connections during skill installation. Only 140.82.121.4:443 (GitHub) was contacted. Pre-existing connections to Ubuntu/Canonical servers were present before install and unrelated to this skill.