2.9 KiB
Modèle de comptes
La commande sudo est inutilisable sur cette machine. L'escalade de privilèges
passe 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 | c'est par là qu'Ansible travaille |
PermitRootLogin prohibit-password : root est joignable par clé, jamais par mot de
passe. Le mot de passe root ne sert donc qu'en local — su - ou la console Proxmox.
AllowUsers est généré à partir des comptes réellement créés : un compte absent ne
peut pas ouvrir de session, même s'il existe sur le système.
Pourquoi sudo n'est pas purgé, contrairement à Debian
Sur Ubuntu, sudo est une dépendance d'ubuntu-minimal. Le purger entraînerait la
suppression du métapaquet, et l'autoremove qui suit pourrait alors emporter
netplan.io, udev ou vim-tiny — de quoi rendre la machine inutilisable.
Le cloud-init applique donc :
dpkg-statoverride --update --add root root 0000 /usr/bin/sudo
rm -f /etc/sudoers.d/90-cloud-init-users
Le binaire perd son bit setuid et tous ses droits : plus personne ne peut l'exécuter.
Le paquet reste installé, la dépendance est satisfaite, et dpkg-statoverride réapplique
ces droits à chaque mise à jour du paquet — c'est précisément sa raison d'être.
Vérification :
ls -l /usr/bin/sudo # doit afficher ----------
sudo -n true # doit échouer
Pour revenir en arrière, si le besoin apparaissait :
dpkg-statoverride --remove /usr/bin/sudo
chmod 4755 /usr/bin/sudo
Où vivent les clés
Un fichier .pub par identité dans key/, référencé par les fichiers vms/*.tfvars.
Ce sont les mêmes clés que dans le dépôt Debian : les recopier évite d'en gérer un
second jeu.
Un compte dont ssh_key_files est vide n'est pas créé. Deux garde-fous avant création :
un fichier référencé mais absent fait échouer le plan, et une valeur qui n'est pas une
clé publique est refusée par une précondition.
root_ssh_key_files doit contenir la clé que Semaphore présente, sans quoi le playbook
se verra refuser la connexion après chaque recréation.
Le mot de passe root
Généré par Terraform à la création, en 24 caractères, et publié en artefact
mot-de-passe-root-<vm> par le workflow deploy, avec une rétention d'un jour :
le télécharger, le déposer dans Vaultwarden, puis supprimer l'artefact.
Il est conservé en clair dans l'état Terraform sur S3 — contrepartie de la génération automatique.
Côté Ansible
La machine n'ayant pas de sudo utilisable, un playbook doit s'y connecter
directement en root : remote_user: root et become: false, comme dans le dépôt
ansible-centreon. L'inventaire généré par Terraform pointe déjà sur root.