Mesure sur forge-01 (par l'agent invite, sans dependre du reseau) : quatre drop-ins SSH coexistent la ou il devrait y en avoir deux. Les roles se sont appeles `chezlepro` avant de porter le nom du moteur ; le renommage a change le fichier DEPOSE sans retirer le precedent. Et les paires divergent : MaxSessions 2 contre 10, MaxStartups 5:30:20 contre 10:30:60. sshd retient la PREMIERE valeur rencontree pour chaque mot-cle et lit les drop-ins dans l'ordre lexical — c'est donc l'ANCIEN fichier qui gagne. Une configuration qu'on croit avoir remplacee reste aux commandes, en silence. ssh_baseline et ssh_hardening retirent chacun le fichier de la nomenclature qu'ils ont abandonnee, AVANT de deposer le leur, et notifient la meme validation. La liste est declarative et ne contient que des noms reellement deposes un jour : supprimer un fichier qu'on n'a jamais ecrit serait effacer la configuration d'un autre. PAS ENCORE EPROUVE : les seules machines portant les anciens fichiers sont celles de patient 0, hors d'atteinte depuis le poste. Ecrit, linte, reste a le voir agir. 42 preuves vertes, ansible-lint profil production. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
19 lines
694 B
YAML
19 lines
694 B
YAML
---
|
|
# VOIR defaults/main.yml : un renommage de role laisse son ancien fichier EN VIGUEUR, et
|
|
# l'ordre lexical le place devant le nouveau. Retirer ce qu'on ne depose plus fait partie
|
|
# du travail de deposer.
|
|
- name: Retirer le hardening SSH d'une nomenclature abandonnee
|
|
ansible.builtin.file:
|
|
path: "/etc/ssh/sshd_config.d/{{ item }}"
|
|
state: absent
|
|
loop: "{{ ssh_hardening_fichiers_perimes }}"
|
|
notify: Validate and reload ssh
|
|
|
|
- name: Déployer le hardening SSH additionnel
|
|
ansible.builtin.template:
|
|
src: 20-setops-hardening.conf.j2
|
|
dest: /etc/ssh/sshd_config.d/20-setops-hardening.conf
|
|
owner: root
|
|
group: root
|
|
mode: "0644"
|
|
notify: Validate and reload ssh
|