Modèle de comptes

La machine n'a pas la commande sudo : elle est purgée par cloud-init et épinglée en priorité négative dans APT, pour qu'aucune dépendance ne la réinstalle en douce. L'escalade de privilèges passe donc par su -.

Compte	Accès SSH	Privilèges	Usage
`hcornet`	clé	aucun	administration humaine, puis `su -`
`invite`	clé	aucun	consultation
`ansible`	clé	aucun	compte de service, sans droits
`root`	clé uniquement	tous	Ansible s'y connecte directement

PermitRootLogin prohibit-password : root est joignable en SSH par clé, jamais par mot de passe. Le mot de passe root ne sert donc qu'en local — su - depuis un compte humain, ou la console Proxmox quand le réseau est cassé.

AllowUsers est généré à partir de la liste des comptes : un compte absent de local_accounts ne peut pas ouvrir de session, même s'il existe sur le système.

Où vivent les clés

Un fichier .pub par identité dans key/, référencé par les fichiers vms/*.tfvars. Rien n'est recopié dans le .tfvars lui-même.

key/
├── hcornet.pub     livré, c'est votre clé
├── invite.pub      à déposer pour activer le compte invite
└── ansible.pub     à déposer pour l'automatisation

Un compte dont ssh_key_files est vide n'est pas créé. invite et ansible sont donc déclarés dans vms/centreon.tfvars mais inactifs : déposer leur .pub et compléter la liste suffit à les activer au prochain déploiement.

Deux garde-fous avant création, faute de quoi une VM inaccessible serait produite et cloud-init ne rejoue rien :

un fichier référencé mais absent fait échouer le plan à la lecture ;
une valeur qui ne ressemble pas à une clé publique est refusée par une précondition.

C'est ce second contrôle qui manquait : la version précédente vérifiait qu'une clé était présente, pas qu'il s'agissait bien d'une clé.

Votre clé donne aussi l'accès root

root_ssh_key_files contient key/hcornet.pub : ssh [email protected] fonctionne directement, sans mot de passe. Votre clé privée est donc un identifiant root à part entière — ce qui rend sa phrase de passe et sa protection d'autant plus importantes.

Le jour où Ansible entre en jeu, ajouter key/ansible.pub à cette même liste.

Le mot de passe root

Il est généré par Terraform à la création de la VM, en 24 caractères. Il n'est jamais affiché dans les journaux : le workflow deploy le publie en artefact mot-de-passe-root, avec une rétention d'un jour.

Marche à suivre après un apply :

télécharger l'artefact depuis la page du job ;
déposer la valeur dans Vaultwarden ;
supprimer l'artefact depuis Gitea.

À savoir : ce mot de passe est conservé en clair dans l'état Terraform, sur S3. C'est la contrepartie de la génération automatique. Si cela devient gênant, l'alternative est que vous le choisissiez vous-même et ne fournissiez que son empreinte — le code passerait alors d'un random_password à une variable root_password_hash produite par openssl passwd -6, et plus rien de sensible ne transiterait.

Conséquence pour Ansible

Le dépôt centreon-ansible doit être repris : ses rôles utilisent become: true avec sudo, qui n'existe plus. La bascule consiste à se connecter en root et à retirer l'escalade — remote_user: root et become: false dans le playbook, l'inventaire généré par Terraform pointant déjà sur root.

Vérifications après création

ssh [email protected] "id && command -v sudo || echo 'sudo absent, conforme'"
ssh -i ~/.ssh/id_ed25519_ansible [email protected] "hostname -f"

La première commande doit montrer un compte sans groupe sudo et confirmer l'absence de la commande. La seconde valide la voie d'accès d'Ansible.

3.8 KiB Raw Permalink Blame History