Donner accès à un collègue

Introduction

Small Frame Studio a besoin qu’Ava et Noah travaillent sur deux hôtes préparés, tandis que Maya conserve son accès et ses notes. Vous créerez des comptes du personnel délimités avec Ansible, utiliserez leurs véritables identités SSH et transformerez une déclaration individuelle en liste réutilisable.

Vous devez savoir naviguer dans un terminal et avoir lu un petit inventaire et un playbook Ansible. Ce laboratoire explique avant utilisation les notions nécessaires de compte Linux, clé SSH, permissions, lookup et boucle. Toutes les clés d’exercice, les identités de serveurs de confiance et la collection distincte sont préparées.

Donnez à Ava un accès utilisable

Dans cette étape, vous créerez un compte du cours sur deux hôtes du studio, autoriserez sa clé d’exercice et utiliserez cette identité pour enregistrer un véritable fichier de travail.

Small Frame Studio conserve des notes éditoriales différentes sur web1 et web2. Maya travaille déjà sur les deux ; Ava a besoin d’un accès sans perdre le travail de Maya. Les cibles préparées sont deux conteneurs SSH partageant le noyau de la VM d’exercice, pas des VM indépendantes. Ansible s’exécute sur le contrôleur et se connecte avec le compte automation préparé. Les comptes du personnel existent uniquement dans ces cibles du cours.

Ouvrez Controller. Il démarre dans le répertoire du projet. Cette commande vous y ramène aussi si vous êtes entré dans un mauvais répertoire :

cd /home/labex/project

Lisez l’inventaire et les données approuvées du personnel avec cat, qui affiche les fichiers sans les modifier :

cat inventory.ini

cat approved-staff.json

La liste finale contient studio_ava et studio_noah pour les deux hôtes. Nous commencerons par Ava, puis étendrons le même travail à une liste. Gardez ces entrées approuvées, l’inventaire et les réglages SSH préparés inchangés.

SSH authentifie un utilisateur sur un hôte distant. Une clé publique peut être installée sur la cible ; sa clé privée correspondante reste sur le client et prouve sa possession. Ici, training-keys/ contient des clés d’exercice neuves et jetables, jamais de véritables identifiants personnels. Les fichiers terminés par .pub sont publics ; le fichier correspondant sans ce suffixe est privé. Ne copiez pas de clés privées sur les cibles et n’affichez pas leur contenu.

Lisez la configuration cliente préparée :

cat clients.conf

Chaque alias, tel que web1-maya, choisit une cible, un utilisateur du cours et une clé privée. -F clients.conf demande à ssh d’utiliser cette configuration du projet. Elle fixe les clés de serveur de confiance, désactive les demandes de mot de passe et la réutilisation des connexions, et ne propose que l’identité sélectionnée. La clé d’hôte identifie le serveur ; la clé publique de l’utilisateur autorise la personne. Elles répondent à des besoins différents. Ne désactivez aucune de ces vérifications de confiance.

Observez d’abord une identité du personnel fonctionnelle. Le texte entre apostrophes est une commande exécutée sur l’hôte distant. Le point-virgule y sépare deux commandes : identifier l’utilisateur, puis lire le fichier de travail local.

ssh -F clients.conf web1-maya 'id -un; cat work/briefing.txt'

Elle affiche studio_maya et les notes du studio Riverside. Lisez l’autre hôte par une nouvelle connexion :

ssh -F clients.conf web2-maya 'id -un; cat work/briefing.txt'

La même identité apparaît, mais avec les notes différentes du studio Hill. Préservez les deux fichiers. La connexion d’Ava doit maintenant échouer, car son compte et son autorisation n’existent pas :

ssh -F clients.conf web1-ava 'id -un'

Attendez-vous à Permission denied (publickey) et au code de sortie 255, sans demande de mot de passe. Un délai de connexion dépassé ou un avertissement de clé d’hôte constitue un autre problème : revenez dans ce répertoire et vérifiez l’inventaire/la configuration inchangés, plutôt que d’affaiblir la confiance SSH.

Un utilisateur Linux possède un répertoire personnel, un shell de connexion et un groupe principal. Le module user crée le compte et, sur ces cibles préparées, son groupe principal homonyme. create_home: true crée son répertoire personnel. become: true utilise l’élévation autorisée du compte automation préparé sur les cibles ; cela ne modifie pas la connexion LabEx.

Écrivez un playbook complet. Dans ce here-document, > remplace le fichier nommé du contrôleur et le délimiteur YAML entre apostrophes empêche l’expansion par le shell. Placez le délimiteur final seul au début d’une ligne. Si un bloc est mal saisi, répétez-le entièrement pour remplacer ce fichier. Si le shell attend toujours un délimiteur final manquant, appuyez sur Ctrl+C pour annuler la saisie inachevée, puis relancez le bloc complet depuis l’invite normale. YAML utilise des espaces pour imbriquer et - pour les éléments de liste.

cat > access.yml <<'YAML'
- name: Give Ava access to the studio hosts
  hosts: all
  become: true
  gather_facts: false
  tasks:
    - name: Create Ava's course account
      ansible.builtin.user:
        name: studio_ava
        shell: /bin/bash
        create_home: true
    - name: Keep Ava's home private
      ansible.builtin.file:
        path: /home/studio_ava
        state: directory
        owner: studio_ava
        group: studio_ava
        mode: '0750'
    - name: Create Ava's work directory
      ansible.builtin.file:
        path: /home/studio_ava/work
        state: directory
        owner: studio_ava
        group: studio_ava
        mode: '0750'
    - name: Authorize Ava's public key
      ansible.posix.authorized_key:
        user: studio_ava
        key: "{{ lookup('file', 'training-keys/ava.pub') }}"
        state: present
YAML

Le module file gère les propriétaires et permissions des répertoires, pas le contenu des fichiers de travail existants. Le mode 0750 donne tous les droits au propriétaire, la lecture/le parcours au groupe principal et aucun droit aux autres utilisateurs ; les chiffres entre apostrophes évitent l’interprétation numérique par YAML. lookup lit une clé publique sur le contrôleur. Les doubles accolades évaluent cette expression. state: present ajoute cette clé en gardant les autres ; il ne remplace pas le fichier de clés entier du compte.

Les modules commençant par ansible.builtin sont fournis avec Core. ansible.posix.authorized_key appartient à une collection distincte, installée hors ligne pour ce projet. Il crée le répertoire .ssh en mode 0700 et authorized_keys en mode 0600, appartenant à l’utilisateur et à son groupe principal. Vous n’avez pas besoin d’installer une collection ni de modifier les paramètres du serveur SSH.

Vérifiez d’abord la syntaxe YAML/playbook :

ansible-playbook access.yml --syntax-check

En cas d’erreur, lisez le fichier/la ligne indiqués, comparez espaces et apostrophes au bloc complet, réécrivez-le et répétez. Il n’est pas nécessaire de réinitialiser la VM. Une prévision en check mode n’est pas fiable pour cette création initiale : une tâche de clés ultérieure ne peut pas utiliser un compte dont une tâche précédente a seulement prévu la création. Appliquez la création déclarée, puis utilisez check mode une fois les comptes existants :

ansible-playbook access.yml

Les deux hôtes doivent terminer sans tâche en échec ni cible inaccessible. Connectez-vous maintenant comme Ava et enregistrez son identité réelle. Dans les apostrophes distantes, umask 027 limite les fichiers créés au maximum à 0640 ; > écrit la sortie de id dans le fichier d’arrivée ; cat le relit. Ce réglage ne s’applique qu’au shell de cette commande distante.

ssh -F clients.conf web1-ava 'umask 027; id -un > work/arrival.txt; cat work/arrival.txt'

ssh -F clients.conf web2-ava 'umask 027; id -un > work/arrival.txt; cat work/arrival.txt'

Les deux affichent studio_ava. Vous avez utilisé une véritable connexion du personnel et écrit un fichier, au-delà d’un simple récapitulatif Ansible réussi. Les fichiers distincts et la connexion de Maya doivent toujours fonctionner.

Réutilisez la déclaration pour une liste du personnel

Dans cette étape, vous remplacerez les détails répétés des comptes par des données structurées et une boucle, ajouterez Noah et confirmerez la convergence sans modifier le travail existant.

Restez dans Controller, à /home/labex/project. Chaque entrée du personnel nécessite un utilisateur du cours et le chemin de sa clé publique sur le contrôleur. Le répertoire préparé group_vars est vide. Un fichier nommé group_vars/all.yml fournit des variables à tous les hôtes de l’inventaire. Écrivez la liste approuvée de deux personnes :

cat > group_vars/all.yml <<'YAML'
staff:
  - name: studio_ava
    key_file: training-keys/ava.pub
  - name: studio_noah
    key_file: training-keys/noah.pub
YAML

Un host_vars/web1.yml correspondant peut fournir une liste pour web1 seulement ; les valeurs de l’hôte remplacent les valeurs partagées par défaut du groupe. Cette unité utilise la même liste sur les deux hôtes, tandis que le challenge fournit des listes approuvées différentes. Les tâches réutilisables n’ont pas besoin de changer.

Une boucle répète une tâche pour chaque entrée de staff. item.name lit le nom courant et item.key_file le chemin de sa clé publique. La même liste pilote la création des comptes, répertoires et autorisations. Remplacez le playbook individuel par sa version réutilisable :

cat > access.yml <<'YAML'
- name: Manage the approved studio staff
  hosts: all
  become: true
  gather_facts: false
  tasks:
    - name: Create each course account
      ansible.builtin.user:
        name: "{{ item.name }}"
        shell: /bin/bash
        create_home: true
      loop: "{{ staff }}"
    - name: Keep each home private
      ansible.builtin.file:
        path: "/home/{{ item.name }}"
        state: directory
        owner: "{{ item.name }}"
        group: "{{ item.name }}"
        mode: '0750'
      loop: "{{ staff }}"
    - name: Create each work directory
      ansible.builtin.file:
        path: "/home/{{ item.name }}/work"
        state: directory
        owner: "{{ item.name }}"
        group: "{{ item.name }}"
        mode: '0750'
      loop: "{{ staff }}"
    - name: Add each approved public key
      ansible.posix.authorized_key:
        user: "{{ item.name }}"
        key: "{{ lookup('file', item.key_file) }}"
        state: present
      loop: "{{ staff }}"
YAML

Gardez le comportement non exclusif par défaut. Une opération exclusive de clés dans une boucle peut retirer une autre clé légitime issue d’une itération précédente. Ce projet ajoute des clés précises puis retire une ancienne clé précise ; il ne remplace pas les ensembles complets de clés de tout le monde.

Vérifiez la syntaxe, puis appliquez. Noah n’existe pas encore : la limite de check mode pour une création initiale s’applique toujours.

ansible-playbook access.yml --syntax-check

ansible-playbook access.yml

Ava ne devrait nécessiter aucun nouveau changement, tandis que Noah est créé sur les deux cibles. Lisez les résultats par élément et confirmez unreachable=0 et failed=0 dans les deux récapitulatifs. Utilisez la véritable identité de Noah pour créer son propre fichier de travail :

ssh -F clients.conf web1-noah 'umask 027; id -un > work/arrival.txt; cat work/arrival.txt'

ssh -F clients.conf web2-noah 'umask 027; id -un > work/arrival.txt; cat work/arrival.txt'

Les deux affichent studio_noah. Les fichiers d’arrivée d’Ava restent les siens ; les notes de Maya ne changent pas. Lisez-les avec leurs identités d’origine :

ssh -F clients.conf web1-ava 'cat work/arrival.txt'

ssh -F clients.conf web2-ava 'cat work/arrival.txt'

ssh -F clients.conf web1-maya 'cat work/briefing.txt'

ssh -F clients.conf web2-maya 'cat work/briefing.txt'

Tous les utilisateurs nécessaires existent maintenant. --check prévoit les changements pris en charge sans les appliquer :

ansible-playbook access.yml --check

Les deux récapitulatifs doivent indiquer changed=0, unreachable=0 et failed=0. Répétez la déclaration réelle :

ansible-playbook access.yml

Elle doit aussi indiquer aucun changement. C’est l’idempotence des comptes, répertoires et autorisations déclarés ; un accès SSH ordinaire peut encore écrire des journaux de connexion. La même boucle peut utiliser une autre liste approuvée sans réécrire son implémentation.

Si une connexion échoue, vérifiez l’alias et l’identité choisis, puis comparez le chemin de clé publique et le nom d’utilisateur aux données approuvées. Corrigez la déclaration du contrôleur et appliquez-la à nouveau. Ne réparez pas une autorisation manquante en copiant une clé privée sur une cible, en rendant un répertoire personnel accessible en écriture à tous ou en désactivant la confiance du serveur.

Résumé

Vous avez créé des comptes du cours, des répertoires de travail privés et des autorisations de clés publiques ; enregistré du travail par de véritables identités SSH ; remplacé les répétitions individuelles par une boucle structurée de personnel ; et confirmé la convergence en préservant les accès et notes existants.