chpasswd mit ubuntu:changeme und ssh_pwauth: true gibt jedem neuen Server ein Login-Passwort, das andere Benutzer und Prozesse darauf oft aus dem Metadatendienst auslesen können, und öffnet SSH für das Erraten von Passwörtern. Und "# cloud-config" mit einem zusätzlichen Leerzeichen führt dazu, dass cloud-init die gesamte Datei ohne Fehlermeldung überspringt, sodass keiner Ihrer Benutzer, Schlüssel oder Sicherheitseinstellungen angewendet wird. Dieser Skill findet diese und die weiteren unten aufgeführten cloud-init-Fehler, bevor Sie starten, und erklärt Ihnen, wie Sie jeden einzelnen beheben.

Ihr Agent führt einen Scanner über #cloud-config-Dateien, cloud.cfg.d-Dateien, Ubuntu-Autoinstall-Dateien, Dateien mit Namen wie user-data sowie cloud-config aus, das in Terraform-Heredocs, CloudFormation-UserData, KubeVirt, LXD-Profilen und Vagrantfiles eingebettet ist. Er kennt die Standardwerte von cloud-init (Passwörter gesperrt, Root-Login aus, chpasswd-Typ hash), die Hash-Formate, die die veraltete chpasswd-Liste akzeptiert, die veralteten Schlüssel mit Bindestrich und Terraform-cloudinit_config-Teile, die keinen Header brauchen; er dekodiert base64- und gzip-Inhalte von write_files und behandelt Template-Platzhalter als gesetzt, aber unbekannt. Er führt niemals cloud-init oder die Befehle aus. Er gibt BLOCK, REVIEW oder NOT FLAGGED zurück, mit Datei, Zeile, Begründung und einem sichereren Vorgehen. Geheimnisse werden niemals ausgegeben.

Was geprüft wird

BLOCK (vor der Auslieferung beheben)

• C01: Passwörter im Klartext (plain_text_passwd, chpasswd als Text oder veraltete Liste, password, ein Klartextwert, wo ein Hash hingehört, das identity-Passwort in Autoinstall sowie Befehle wie echo oder printf in chpasswd oder passwd, chpasswd <<< und openssl passwd mit einem Literal)
• C02: SSH-Login per Passwort aktiviert (ssh_pwauth, PasswordAuthentication yes), während ein Konto ein nutzbares Passwort erhält (ein reines Root-Passwort zählt nur bei PermitRootLogin yes, da OpenSSH standardmäßig prohibit-password verwendet)
• C03: als Root ausgeführter Code, der über einfaches HTTP oder mit deaktivierter Zertifikatsprüfung abgerufen wird: curl oder wget, in eine Shell geleitet (auch über tee) oder gespeichert und dann ausgeführt, ausführbar gemacht oder mit dpkg, rpm oder apt installiert, rpm- oder dnf-Installationen von http-URLs, apt trusted=yes oder yum/zypper gpgcheck off über http, ausführbare write_files-Quellen, Installer-URLs von Ansible, Puppet und Chef
• C04: private Schlüssel und Zugangsdaten in User-Data: PEM-Schlüssel (auch in base64- oder gzip-Inhalten und ssh_keys), bekannte Token-Formate, Passwörter in URLs, Authorization-Header, WireGuard-Schlüssel, Einstellungen mit geheimen Namen und Geheimnisse in Befehlszeilen (docker oder az login -p, --token, htpasswd -b, rabbitmqctl add_user und andere)

REVIEW (vor dem Release prüfen)

• C11: Skripte oder Pakete, die über https heruntergeladen und ohne Prüfsummen- oder Signaturprüfung ausgeführt oder installiert werden
• C12: Root-Login erlaubt (disable_root: false, Root-Eintrag oder -Passwort in users, PermitRootLogin yes)
• C13: NOPASSWD-sudo für alle Benutzer, eine Gruppe, ein Systemkonto oder einen Benutzer, der auch ein Passwort hat, in users-Einträgen oder sudoers-Dateien, die per write_files oder echo/tee geschrieben werden (Administratoren nur mit Schlüssel werden nicht gemeldet)
• C14: lock_passwd: false für einen Benutzer, der ein Passwort erhält
• C15: TLS- oder Signaturprüfung über https deaktiviert (curl -k, apt trusted=yes, gpgcheck off, --allow-unauthenticated, snap --dangerous, pip --trusted-host und andere)
• C16: write_files-Berechtigungen, mit denen jeder schreiben kann, oder eine Berechtigung ohne Anführungszeichen wie 644, die YAML als Dezimalzahl liest
• C17: Dateien, die cloud-init nicht als cloud-config liest (falsch geschriebener Header, auch innerhalb eines Heredocs, ein Kommentar oder --- davor, gar kein Header, eine Byte-Order-Mark oder UTF-16)

Was enthalten ist

• Der Scanner (Python 3.9+, nur Standardbibliothek)
• Ein Regelleitfaden mit Begründung, sichererem Vorgehen und Link zur offiziellen Dokumentation für jede Regel
• Ein riskantes und ein sicheres Beispielprojekt (cloud-config, Terraform und ein NoCloud-Seed) sowie der echte Bericht, den der Scanner für das riskante Projekt erzeugt

Grenzen

Er liest jede Datei so, wie sie geschrieben ist. Werte, die ein Template einsetzt (Terraform, Jinja, Helm), sind unbekannt; MIME-Multipart-User-Data, #include-URLs, komprimierte User-Data, Shell-Skripte als User-Data und Vendor-Data werden nicht gelesen, und als JSON-String gespeichertes cloud-config wird nicht gefunden. Shell-Befehle werden per Muster abgeglichen, nicht geparst. Ubuntu-Pro-Tokens und Red-Hat-Aktivierungsschlüssel werden nicht gemeldet. Einige offizielle cloud-init-Beispiele werden absichtlich gemeldet, weil sie ein Klartextpasswort, ein Kontopasswort, einen Basic-Auth-Header, einen Demo-Privatschlüssel oder einen privaten Host-Schlüssel in User-Data zeigen. NOT FLAGGED ist keine Garantie.

Inhalt

Eine ZIP-Datei mit 16 Dateien: SKILL.md, der Scanner in scripts/ (7 Python-Dateien), references/rules.md (jede Regel mit Begründung und sichererem Vorgehen) und examples/ (6 Beispieldateien plus report.md, die echte Ausgabe des Scanners für das riskante Beispiel).

So verwenden Sie es: Dies ist ein Agent-Skill: ein Ordner mit einer SKILL.md-Datei und Python-Skripten, die ein KI-Coding-Agent wie Claude Code, Cursor oder Codex CLI ausführen kann. Entpacken Sie ihn in den Skills-Ordner Ihres Agents (für Claude Code: ~/.claude/skills/) und bitten Sie Ihren Agent dann, Ihr Projekt zu prüfen. Die Skripte laufen auch eigenständig mit Python 3.9 oder neuer, ohne dass etwas installiert werden muss. Sie lesen nur Ihre Dateien: kein Netzwerkzugriff, und nichts wird irgendwohin gesendet.