chpasswd avec ubuntu:changeme et ssh_pwauth: true donne à chaque nouveau serveur un mot de passe de connexion que d'autres utilisateurs et processus de ce serveur peuvent souvent lire depuis le service de métadonnées, et ouvre SSH aux tentatives de devinette de mots de passe. Et "# cloud-config" avec un espace en trop fait que cloud-init ignore tout le fichier sans aucune erreur, si bien qu'aucun de vos utilisateurs, clés ou paramètres de sécurité n'est appliqué. Cette skill détecte ces erreurs et les autres erreurs cloud-init ci-dessous avant le lancement, et vous indique comment corriger chacune d'elles.

Votre agent exécute un scanner sur les fichiers #cloud-config, les fichiers cloud.cfg.d, les fichiers d'installation automatique Ubuntu (autoinstall), les fichiers nommés comme user-data et le cloud-config intégré dans des heredocs Terraform, des UserData CloudFormation, KubeVirt, des profils LXD et des Vagrantfiles. Il connaît les valeurs par défaut de cloud-init (mots de passe verrouillés, connexion root désactivée, type chpasswd hash), les formats de hachage acceptés par l'ancienne liste chpasswd, les anciennes clés avec trait d'union et les parties cloudinit_config de Terraform qui n'ont pas besoin d'en-tête ; il décode le contenu base64 et gzip de write_files et traite les espaces réservés de modèles comme définis mais inconnus. Il n'exécute jamais cloud-init ni les commandes. Il renvoie BLOCK, REVIEW ou NOT FLAGGED, avec le fichier, la ligne, la raison et une approche plus sûre. Les secrets ne sont jamais affichés.

Ce qui est vérifié

BLOCK (à corriger avant la mise en production)

• C01 : mots de passe en clair (plain_text_passwd, chpasswd sous forme de texte ou d'ancienne liste, password, une valeur en clair là où un hachage est attendu, le mot de passe identity d'autoinstall, ainsi que des commandes comme echo ou printf vers chpasswd ou passwd, chpasswd <<< et openssl passwd avec un littéral)
• C02 : connexion SSH par mot de passe activée (ssh_pwauth, PasswordAuthentication yes) alors qu'un compte reçoit un mot de passe utilisable (un mot de passe pour root seul ne compte qu'avec PermitRootLogin yes, puisque OpenSSH utilise prohibit-password par défaut)
• C03 : code exécuté en root et récupéré via HTTP simple ou avec la vérification des certificats désactivée : curl ou wget redirigé vers un shell (y compris via tee) ou enregistré puis exécuté, rendu exécutable ou installé avec dpkg, rpm ou apt, installations rpm ou dnf depuis des URL http, apt trusted=yes ou gpgcheck off pour yum/zypper via http, sources write_files exécutables, URL d'installation d'Ansible, Puppet et Chef
• C04 : clés privées et identifiants dans les user-data : clés PEM (y compris dans du contenu base64 ou gzip et dans ssh_keys), formats de jetons connus, mots de passe dans des URL, en-têtes Authorization, clés WireGuard, paramètres aux noms de secrets et secrets en ligne de commande (docker ou az login -p, --token, htpasswd -b, rabbitmqctl add_user et autres)

REVIEW (à vérifier avant la publication)

• C11 : scripts ou paquets téléchargés via https puis exécutés ou installés sans vérification de somme de contrôle ni de signature
• C12 : connexion root autorisée (disable_root: false, entrée root dans users ou mot de passe, PermitRootLogin yes)
• C13 : sudo NOPASSWD pour tous les utilisateurs, un groupe, un compte système ou un utilisateur qui a aussi un mot de passe, dans des entrées users ou des fichiers sudoers écrits par write_files ou echo/tee (les administrateurs utilisant uniquement une clé ne sont pas signalés)
• C14 : lock_passwd: false pour un utilisateur qui reçoit un mot de passe
• C15 : vérifications TLS ou de signature désactivées via https (curl -k, apt trusted=yes, gpgcheck off, --allow-unauthenticated, snap --dangerous, pip --trusted-host et autres)
• C16 : permissions write_files accessibles en écriture à tous, ou une permission sans guillemets comme 644 que YAML lit comme un nombre décimal
• C17 : fichiers que cloud-init ne lira pas comme cloud-config (en-tête mal orthographié, y compris dans un heredoc, un commentaire ou --- avant celui-ci, aucun en-tête, une marque d'ordre des octets ou de l'UTF-16)

Ce qui est inclus

• Le scanner (Python 3.9+, bibliothèque standard uniquement)
• Un guide des règles avec la raison, une approche plus sûre et un lien vers la documentation officielle pour chaque règle
• Un projet d'exemple risqué et un projet sûr (cloud-config, Terraform et un seed NoCloud), ainsi que le rapport réel produit par le scanner sur le projet risqué

Limites

Il lit chaque fichier tel qu'il est écrit. Les valeurs remplies par un modèle (Terraform, Jinja, Helm) sont inconnues ; les user-data MIME multi-parties, les URL #include, les user-data compressés, les scripts shell en user-data et les vendor-data ne sont pas lus, et le cloud-config stocké sous forme de chaîne JSON n'est pas détecté. Les commandes shell sont repérées par motif, pas analysées. Les jetons Ubuntu Pro et les clés d'activation Red Hat ne sont pas signalés. Certains exemples officiels de cloud-init sont signalés volontairement, car ils montrent un mot de passe en clair, un mot de passe de compte, un en-tête Basic auth, une clé privée de démonstration ou une clé privée d'hôte dans les user-data. NOT FLAGGED n'est pas une garantie.

Contenu

Un fichier ZIP de 16 fichiers : SKILL.md, le scanner dans scripts/ (7 fichiers Python), references/rules.md (chaque règle avec sa raison et une approche plus sûre) et examples/ (6 fichiers d'exemple plus report.md, la sortie réelle du scanner sur l'exemple risqué).

Mode d'emploi : Il s'agit d'une skill pour agent : un dossier contenant un fichier SKILL.md et des scripts Python qu'un agent de codage IA comme Claude Code, Cursor ou Codex CLI peut exécuter. Décompressez-la dans le dossier des skills de votre agent (pour Claude Code : ~/.claude/skills/), puis demandez à votre agent de vérifier votre projet. Les scripts fonctionnent aussi seuls avec Python 3.9 ou une version plus récente, sans rien à installer. Ils se contentent de lire vos fichiers : aucun accès réseau, et rien n'est envoyé nulle part.