Introduction
L'accès aux nœuds gérés est le fondement de l'automatisation avec Ansible. Dans des environnements réels, Ansible se connecte généralement via SSH et utilise l'élévation de privilèges pour les tâches administratives.
Dans ce laboratoire, la configuration crée un utilisateur géré temporaire nommé rhce_node. Vous générerez une clé SSH, l'autoriserez pour cet utilisateur, configurerez l'accès à l'inventaire et vérifierez à la fois l'exécution SSH standard et l'accès via become.
Créer le projet de pratique SSH
Dans cette étape, vous allez créer les répertoires du projet et les paramètres par défaut d'Ansible pour l'accès via SSH. Le compte géré existe déjà, mais il ne fait pas encore confiance à votre clé.
Créez et accédez au répertoire du projet.
cd /home/labex/project
mkdir -p rhce-ansible/{inventory,keys,playbooks}
cd rhce-ansible
Créez le fichier ansible.cfg.
cat > ansible.cfg <<'EOF'
[defaults]
inventory = ./inventory/hosts
host_key_checking = False
retry_files_enabled = False
interpreter_python = auto_silent
EOF
Ce projet utilise une connexion SSH réelle vers 127.0.0.1 plus tard dans le laboratoire. Le répertoire keys permet de séparer la paire de clés du laboratoire de vos fichiers ~/.ssh habituels, et host_key_checking = False évite une invite interactive pendant cet exercice local contrôlé.
Générer une paire de clés SSH
Dans cette étape, vous allez créer une paire de clés SSH Ed25519. La clé privée restera dans keys/rhce_ed25519 ; la clé publique peut être installée en toute sécurité sur un compte géré. L'option -N '' crée une clé sans phrase secrète pour l'automatisation du laboratoire.
Avant d'exécuter les commandes de cette étape, retournez dans le répertoire du projet Ansible. Cela garantit la stabilité des commandes, même si LabEx exécute chaque étape séparément.
cd /home/labex/project/rhce-ansible
Générez la paire de clés.
ssh-keygen -t ed25519 -f keys/rhce_ed25519 -N '' -C rhce-ansible-lab
Cela crée deux fichiers. keys/rhce_ed25519 est la clé privée et doit rester confidentielle ; keys/rhce_ed25519.pub est la clé publique qui peut être installée sur le compte de l'utilisateur géré.
Inspectez la clé publique.
cat keys/rhce_ed25519.pub
La ligne de la clé publique doit commencer par ssh-ed25519 et se terminer par le commentaire rhce-ansible-lab. Vous copierez cette clé publique, et non la clé privée, dans authorized_keys.
Autoriser la clé pour l'utilisateur géré
Dans cette étape, vous allez installer la clé publique pour l'utilisateur géré temporaire. Vous ne modifiez pas l'accès SSH LabEx pour l'utilisateur labex ; vous préparez uniquement rhce_node pour ce laboratoire.
Avant d'exécuter les commandes de cette étape, retournez dans le répertoire du projet Ansible.
cd /home/labex/project/rhce-ansible
Créez le répertoire .ssh de l'utilisateur géré.
sudo mkdir -p /home/rhce_node/.ssh
SSH recherche les clés publiques approuvées dans le répertoire .ssh de l'utilisateur. Vous avez besoin de sudo ici car le répertoire appartient au répertoire personnel d'un autre utilisateur.
Installez votre clé publique en tant que authorized_keys.
sudo cp keys/rhce_ed25519.pub /home/rhce_node/.ssh/authorized_keys
Corrigez la propriété et les permissions. SSH refuse les clés lorsque les répertoires ou les fichiers sont trop ouverts.
sudo chown -R rhce_node:rhce_node /home/rhce_node/.ssh
sudo chmod 700 /home/rhce_node/.ssh
sudo chmod 600 /home/rhce_node/.ssh/authorized_keys
Les valeurs de permission sont délibérées : 700 permet uniquement à rhce_node d'accéder au répertoire .ssh, et 600 permet uniquement à cet utilisateur de lire ou d'écrire dans authorized_keys. Ces vérifications empêchent l'exposition accidentelle des informations de connexion.
Configurer l'inventaire pour l'accès SSH
Dans cette étape, vous allez créer une entrée d'inventaire qui indique à Ansible comment se connecter à l'utilisateur géré via SSH sur localhost.
Avant d'exécuter les commandes de cette étape, retournez dans le répertoire du projet Ansible.
cd /home/labex/project/rhce-ansible
Rédigez l'inventaire.
cat > inventory/hosts <<'EOF'
[managed]
node1 ansible_host=127.0.0.1 ansible_user=rhce_node ansible_ssh_private_key_file=/home/labex/project/rhce-ansible/keys/rhce_ed25519
EOF
Cette ligne d'inventaire sépare le nom Ansible des détails de connexion. node1 est l'alias de l'inventaire, ansible_host est l'adresse de connexion, ansible_user est le compte distant, et ansible_ssh_private_key_file pointe vers la clé privée.
Testez directement SSH avant d'utiliser Ansible.
ssh -i keys/rhce_ed25519 -o StrictHostKeyChecking=no rhce_node@127.0.0.1 'whoami'
La commande devrait afficher rhce_node.
Tester SSH directement permet de restreindre le champ des problèmes si Ansible échoue plus tard. Si la connexion SSH directe ne fonctionne pas, corrigez la clé, la propriété, les permissions ou les valeurs de connexion de l'inventaire avant de dépanner les modules Ansible.
Valider le ping Ansible et l'élévation de privilèges
Dans cette étape, vous allez tester la connectivité Ansible et l'élévation de privilèges. L'option -b signifie become, ce qui demande à Ansible d'exécuter le module avec des privilèges élevés.
Avant d'exécuter les commandes de cette étape, retournez dans le répertoire du projet Ansible.
cd /home/labex/project/rhce-ansible
Exécutez le module ping d'Ansible via SSH.
ansible managed -m ansible.builtin.ping
Cette fois, le module ping n'utilise pas de raccourci de connexion locale. Ansible doit se connecter en tant que rhce_node, transférer un petit module, l'exécuter avec Python et renvoyer pong.
Exécutez une commande avec élévation de privilèges. La commande id -u affiche 0 lorsqu'elle est exécutée en tant que root.
ansible managed -b -m ansible.builtin.command -a 'id -u'
Le drapeau -b active become pour cette commande. Un résultat contenant 0 prouve que l'utilisateur géré peut s'élever via la règle sudoers créée pour le laboratoire.
Écrivez un fichier appartenant à root en utilisant become d'Ansible.
ansible managed -b -m ansible.builtin.copy -a 'content=become_ready dest=/etc/rhce-ansible-become.txt mode=0644'
L'écriture dans /etc nécessite des privilèges administratifs, donc cette commande finale prouve bien plus que la simple connectivité. Elle confirme qu'Ansible peut à la fois se connecter via SSH et effectuer des modifications système privilégiées lorsque cela est demandé.
Résumé
Vous avez généré une paire de clés SSH, l'avez autorisée pour un utilisateur géré temporaire, configuré l'accès à l'inventaire via SSH et validé l'élévation de privilèges avec become d'Ansible.
