Introduction
Ava a remplacé un ancien ordinateur portable du studio. Les deux hôtes préparés acceptent toujours sa clé, en plus des clés actuelle et de secours. Retirez seulement l’autorisation de l’ancien appareil en préservant son compte et ses notes originales.
Cette unité indépendante suppose la pratique des utilisateurs, clés publiques, lookup et boucles de Donner accès à un collègue. Ses propres clés d’exercice et comptes existants sont préparés ; aucun fichier ni connexion ne provient de la VM précédente.
Retirez la clé d’un ancien appareil
Dans cette étape, vous révoquerez la clé de l’ancien appareil d’Ava sur les deux hôtes du studio, prouverez le refus des nouvelles connexions et préserverez sa clé actuelle, sa clé de secours et son travail original.
Cette unité possède son propre environnement neuf. Ava dispose déjà de comptes et de travail sur les deux cibles. Chaque compte accepte actuellement trois clés d’exercice : actuelle, de secours et ancien appareil. Vous retirerez uniquement l’ancienne autorisation. Supprimer une clé bloque les nouvelles authentifications avec elle ; cela ne termine pas une connexion déjà authentifiée. Ce laboratoire teste les nouvelles connexions et ne prétend pas terminer des sessions.
Ouvrez Controller et entrez dans le répertoire du projet. Cette commande permet aussi de récupérer après un changement accidentel de répertoire :
cd /home/labex/project
Lisez les entrées préparées et les alias du client :
cat approved-staff.json
cat clients.conf
Le compte approuvé est studio_ava. La clé à révoquer est training-keys/ava-old.pub ; training-keys/ava.pub et training-keys/ava-backup.pub restent autorisées. Les fichiers terminés par .pub sont publics ; les clés privées correspondantes restent sur ce client d’exercice. Les alias choisissent l’hôte, l’utilisateur et la clé exacte. -F clients.conf sélectionne cette configuration du projet à confiance fixée ; chaque appel ssh crée une nouvelle connexion. Gardez l’inventaire, les paramètres clients, la confiance des hôtes et les clés d’exercice inchangés.
Observez le comportement normal avant de modifier l’accès. Dans les apostrophes, le shell distant exécute id puis cat, séparés par un point-virgule :
ssh -F clients.conf web1-ava 'id -un; cat work/briefing.txt'
ssh -F clients.conf web2-ava 'id -un; cat work/briefing.txt'
L’identité est studio_ava sur les deux, mais les notes Riverside et Hill diffèrent. Vérifiez aussi la clé de secours :
ssh -F clients.conf web1-ava-backup 'id -un'
ssh -F clients.conf web2-ava-backup 'id -un'
L’ancien appareil est encore accepté à ce stade :
ssh -F clients.conf web1-ava-old 'id -un'
ssh -F clients.conf web2-ava-old 'id -un'
Supprimer simplement une clé d’une liste de clés à ajouter ne demande pas son retrait. Observez cette différence sans risque avec une liste d’ajouts vide. Le here-document écrit un fichier entier du contrôleur : > remplace ce fichier et YAML entre apostrophes empêche l’expansion du shell. Terminez par le délimiteur seul en début de ligne. Si le shell attend encore un délimiteur final manquant, appuyez sur Ctrl+C pour annuler la saisie inachevée, puis relancez le bloc complet depuis l’invite normale. Une boucle sur [], une liste YAML vide, n’a aucun élément à traiter.
cat > additions.yml <<'YAML'
- name: Add listed keys without removing other grants
hosts: all
become: true
gather_facts: false
vars:
keys_to_add: []
tasks:
- name: Add a listed key
ansible.posix.authorized_key:
user: studio_ava
key: "{{ lookup('file', item) }}"
state: present
loop: "{{ keys_to_add }}"
YAML
ansible-playbook additions.yml
La tâche de clés est ignorée sur les deux hôtes et aucun ne change. Elle n’a pas inspecté toutes les autorisations possibles pour retirer les clés absentes de la liste. L’ancien appareil peut toujours se connecter :
ssh -F clients.conf web1-ava-old 'id -un'
Exprimez maintenant la vraie révocation. group_vars/all.yml fournit cette liste aux deux hôtes de l’inventaire sans modifier le fichier d’approbation préparé. Chaque objet indique un utilisateur du cours et un chemin de clé publique sur le contrôleur. Répéter un bloc de fichier mal saisi remplace ce fichier du contrôleur ; cela ne nécessite pas de réinitialiser la VM.
cat > group_vars/all.yml <<'YAML'
revoked_keys:
- name: studio_ava
key_file: training-keys/ava-old.pub
YAML
Utilisez le module appris avec state: absent, qui retire cette clé en préservant le compte et ses autres autorisations. Une boucle traite chaque retrait listé. Les doubles accolades résolvent l’entrée courante ; lookup lit la clé publique sur le contrôleur. La collection est installée hors ligne pour ce projet. N’utilisez pas de remplacement exclusif, ne supprimez pas de répertoires personnels, ne verrouillez pas de mots de passe et ne modifiez pas le service SSH de la plateforme.
cat > revoke.yml <<'YAML'
- name: Revoke only the approved old device keys
hosts: all
become: true
gather_facts: false
tasks:
- name: Remove each listed old public key
ansible.posix.authorized_key:
user: "{{ item.name }}"
key: "{{ lookup('file', item.key_file) }}"
state: absent
loop: "{{ revoked_keys }}"
YAML
Vérifiez la syntaxe. En cas d’erreur YAML, lisez la ligne indiquée, comparez indentation/apostrophes au bloc complet et réécrivez seulement ce fichier du contrôleur.
ansible-playbook revoke.yml --syntax-check
Ces comptes existent déjà : check mode peut donc prévoir le retrait de clé pris en charge. --diff afficherait les lignes de clés publiques, inutiles pour cette prévision. Utilisez --check :
ansible-playbook revoke.yml --check
Les deux hôtes doivent prévoir un changement. Check mode n’a pas encore révoqué l’autorisation réelle. Appliquez-la :
ansible-playbook revoke.yml
Les deux hôtes doivent terminer sans cible inaccessible ni tâche en échec. Les deux connexions suivantes doivent échouer avec Permission denied (publickey) et le code de sortie 255 :
ssh -F clients.conf web1-ava-old 'id -un'
ssh -F clients.conf web2-ava-old 'id -un'
Un délai dépassé, un refus de connexion ou un avertissement de clé d’hôte ne prouve pas la révocation. Le serveur doit rester disponible et les clés autorisées fonctionner. Créez de nouvelles connexions avec les clés actuelle et de secours pour lire les deux fichiers originaux :
ssh -F clients.conf web1-ava 'id -un; cat work/briefing.txt'
ssh -F clients.conf web2-ava 'id -un; cat work/briefing.txt'
ssh -F clients.conf web1-ava-backup 'id -un; cat work/briefing.txt'
ssh -F clients.conf web2-ava-backup 'id -un; cat work/briefing.txt'
Les quatre doivent réussir comme studio_ava et afficher les notes originales correspondantes. Gardez leurs octets, propriétaire et mode 0640 ; conservez 0750 pour les répertoires personnel/de travail, 0700 pour .ssh et 0600 pour authorized_keys. Les fichiers appartiennent à studio_ava et à son groupe principal. Le module existant préserve ces permissions sûres préparées.
Répétez la déclaration réelle, puis sa prévision :
ansible-playbook revoke.yml
ansible-playbook revoke.yml --check
Les deux récapitulatifs doivent indiquer changed=0, unreachable=0 et failed=0. Une révocation correcte est une modification ciblée de l’autorisation réelle, pas seulement un récapitulatif réussi ou une liste vide sur le contrôleur. Si vous avez choisi le mauvais chemin, corrigez les données du contrôleur ; restaurez la clé autorisée retirée par erreur avec state: present, déjà appris, puis réappliquez le bon retrait ciblé. Ne récupérez pas l’accès en vidant tout le fichier de clés ou en le rendant accessible en écriture à tous.
Résumé
Vous avez distingué une addition omise d’une révocation explicite, retiré une autorisation de clé publique avec state absent, vérifié le véritable refus des nouvelles connexions et conservé les connexions actuelles/de secours et les deux fichiers originaux. Une déclaration inchangée a convergé sans modification inutile.
