Comment définir l'utilisateur SSH par défaut pour les connexions Ansible

Introduction

Ansible est un outil d'automatisation puissant qui simplifie la gestion des serveurs distants. Un aspect crucial d'Ansible est la capacité d'établir des connexions SSH sécurisées vers ces serveurs. Dans ce tutoriel, nous allons explorer comment définir l'utilisateur SSH par défaut pour les connexions Ansible, garantissant ainsi un flux de travail fluide et efficace pour vos tâches de gestion de serveur.

Installation et configuration d'Ansible

Avant de configurer l'utilisateur SSH pour Ansible, nous devons nous assurer qu'Ansible est correctement installé et configuré sur notre système.

Installation d'Ansible

Commençons par installer Ansible. Ouvrez un terminal et exécutez les commandes suivantes :

sudo apt update
sudo apt install -y ansible

Une fois l'installation terminée, vérifiez qu'Ansible est correctement installé en vérifiant sa version :

ansible --version

Vous devriez voir une sortie similaire à la suivante :

ansible [core 2.12.x]
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/home/labex/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3/dist-packages/ansible
  ansible collection location = /home/labex/.ansible/collections:/usr/share/ansible/collections
  executable location = /usr/bin/ansible
  python version = 3.10.x (main, Ubuntu, x86_64)
  jinja version = 3.0.3
  libyaml = True

Création d'un répertoire de travail Ansible

Ensuite, créons une structure de répertoire pour notre projet Ansible. Cela nous aidera à organiser nos fichiers :

mkdir -p ~/project/ansible/inventory
cd ~/project/ansible

Création d'un fichier d'inventaire de base

Ansible utilise des fichiers d'inventaire pour définir les hôtes qu'il gère. Créons un fichier d'inventaire simple :

echo "[webservers]
localhost ansible_connection=local" > ~/project/ansible/inventory/hosts

Ce fichier d'inventaire définit un groupe appelé webservers avec un seul hôte, localhost, et indique à Ansible d'utiliser une connexion locale plutôt que SSH pour cet hôte.

Maintenant, vérifions notre inventaire :

ansible -i inventory/hosts --list-hosts all

Vous devriez voir une sortie comme :

  hosts (1):
    localhost

Cela montre qu'Ansible reconnaît notre inventaire et les hôtes qui y sont définis.

Comprendre les connexions et la configuration SSH d'Ansible

Ansible utilise principalement SSH pour se connecter aux hôtes distants et exécuter des commandes. Explorons comment Ansible établit les connexions SSH et comment nous pouvons configurer l'utilisateur SSH par défaut.

Comment Ansible utilise SSH

Par défaut, Ansible tente d'utiliser votre utilisateur système actuel pour établir des connexions SSH. Cela signifie que si vous êtes connecté en tant qu'utilisateur labex et que vous exécutez une commande Ansible, Ansible essaiera de se connecter aux hôtes distants en tant qu'utilisateur labex.

Ce comportement par défaut n'est pas toujours celui que vous souhaitez. Par exemple :

• Le serveur distant peut nécessiter un utilisateur différent pour l'accès.
• Vous souhaiterez peut-être utiliser un utilisateur dédié aux tâches d'automatisation.
• Différents serveurs peuvent nécessiter des utilisateurs différents.

Hiérarchie de configuration d'Ansible

Ansible utilise une hiérarchie de sources de configuration pour déterminer quel utilisateur SSH utiliser :

1. Options de ligne de commande (priorité la plus élevée)
2. Options spécifiques aux tâches dans les playbooks
3. Variables d'hôte et de groupe dans l'inventaire
4. Fichier de configuration Ansible
5. Valeurs par défaut (priorité la plus basse)

Créons un fichier de configuration Ansible de base pour mieux comprendre cela :

cat > ~/project/ansible/ansible.cfg << 'EOF'
[defaults]
inventory = ./inventory/hosts
host_key_checking = False
EOF

Ce fichier de configuration indique à Ansible de :

• Utiliser notre fichier d'inventaire par défaut
• Désactiver la vérification des clés d'hôte (utile pour les tests dans les environnements de laboratoire)

Examinons le fichier que nous venons de créer :

cat ~/project/ansible/ansible.cfg

Vous devriez voir le contenu que nous venons d'ajouter au fichier.

Test d'une commande Ansible de base

Exécutons maintenant une commande Ansible de base pour voir l'utilisateur actuel :

cd ~/project/ansible
ansible localhost -m command -a "whoami"

La sortie devrait afficher :

localhost | CHANGED | rc=0 >>
labex

Cela confirme qu'Ansible exécute les commandes en tant qu'utilisateur actuel (labex).

Définir l'utilisateur SSH par défaut pour Ansible

Maintenant que nous comprenons comment Ansible utilise SSH, explorons différentes manières de définir l'utilisateur SSH par défaut pour nos connexions.

Méthode 1 : Utilisation du fichier de configuration Ansible

La manière la plus simple de définir un utilisateur SSH par défaut global est d'utiliser le fichier de configuration Ansible. Modifions notre fichier ansible.cfg :

cat > ~/project/ansible/ansible.cfg << 'EOF'
[defaults]
inventory = ./inventory/hosts
host_key_checking = False
remote_user = ansible_user
EOF

Dans cette configuration, nous avons ajouté le paramètre remote_user, qui indique à Ansible d'utiliser ansible_user comme utilisateur SSH par défaut pour toutes les connexions.

Méthode 2 : Définir l'utilisateur dans le fichier d'inventaire

Une autre approche consiste à définir l'utilisateur SSH dans le fichier d'inventaire. Cette méthode vous permet de définir différents utilisateurs pour différents hôtes ou groupes.

Modifions notre fichier d'inventaire :

cat > ~/project/ansible/inventory/hosts << 'EOF'
[webservers]
localhost ansible_connection=local

[dbservers]
db.example.com ansible_user=db_admin

[all:vars]
ansible_user=default_user
EOF

Dans cet exemple :

• Nous avons ajouté un nouveau groupe appelé dbservers avec un hôte db.example.com et spécifié qu'Ansible doit utiliser l'utilisateur db_admin lors de la connexion à cet hôte.
• Nous avons également ajouté une variable de groupe ansible_user=default_user qui s'applique à tous les hôtes, sauf en cas de substitution.

Méthode 3 : Utilisation des options de ligne de commande

Vous pouvez également spécifier l'utilisateur SSH directement dans la ligne de commande lors de l'exécution des commandes Ansible :

ansible localhost -m command -a "whoami" -u specific_user

L'option -u indique à Ansible d'utiliser specific_user pour cette commande spécifique, en remplaçant tout utilisateur défini dans les fichiers de configuration ou l'inventaire.

Méthode 4 : Définir l'utilisateur dans les playbooks

Lors de l'utilisation des playbooks Ansible, vous pouvez spécifier l'utilisateur SSH au niveau du play :

Créons un playbook simple pour le démontrer :

cat > ~/project/ansible/user_demo.yml << 'EOF'
---
- name: Demonstrate user configuration
  hosts: localhost
  remote_user: playbook_user
  
  tasks:
    - name: Show current user
      command: whoami
      register: current_user
      
    - name: Display current user
      debug:
        msg: "Current user is {{ current_user.stdout }}"
EOF

Dans ce playbook, le paramètre remote_user définit l'utilisateur SSH sur playbook_user pour toutes les tâches de ce play.

Priorité des utilisateurs dans Ansible

Il est important de comprendre la priorité de ces différentes méthodes :

1. Les options de ligne de commande (option -u) ont la priorité la plus élevée.
2. Paramètres au niveau de la tâche dans les playbooks
3. Paramètres au niveau du play dans les playbooks
4. Variables d'hôte dans l'inventaire
5. Variables de groupe dans l'inventaire
6. Paramètres du fichier de configuration (remote_user dans ansible.cfg)
7. Utilisateur système par défaut (priorité la plus basse)

Cela signifie que les paramètres utilisateur les plus spécifiques remplacent les paramètres les plus généraux.

Tester et vérifier la configuration de l'utilisateur SSH

Maintenant que nous avons configuré l'utilisateur SSH par défaut de différentes manières, testons et vérifions notre configuration.

Tester le paramètre du fichier de configuration

Tout d'abord, exécutons une simple commande Ansible pour voir si les paramètres de notre fichier de configuration sont appliqués :

cd ~/project/ansible
ansible localhost -m command -a "whoami"

Puisque nous nous connectons à localhost avec ansible_connection=local, Ansible exécutera toujours les commandes en tant qu'utilisateur actuel, quel que soit le paramètre remote_user. Cependant, s'il s'agissait d'une connexion distante, Ansible tenterait d'utiliser l'utilisateur ansible_user que nous avons spécifié dans la configuration.

Utilisation de ansible-inventory pour vérifier les paramètres utilisateur

Ansible fournit une commande appelée ansible-inventory qui nous permet de voir comment Ansible interprète notre inventaire, y compris les paramètres de l'utilisateur SSH :

ansible-inventory --list

Cette commande affiche une représentation JSON de l'inventaire, montrant toutes les variables associées à chaque hôte, y compris les paramètres de l'utilisateur SSH.

Tester les paramètres utilisateur avec un playbook

Exécutons le playbook que nous avons créé à l'étape précédente :

ansible-playbook user_demo.yml

La sortie affichera quelque chose comme :

PLAY [Demonstrate user configuration] ******************************************

TASK [Gathering Facts] *********************************************************
ok: [localhost]

TASK [Show current user] *******************************************************
changed: [localhost]

TASK [Display current user] ****************************************************
ok: [localhost] => {
    "msg": "Current user is labex"
}

PLAY RECAP *********************************************************************
localhost                  : ok=3    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

La sortie montre que la commande est toujours exécutée en tant qu'utilisateur labex, ce qui est attendu car nous nous connectons à localhost avec ansible_connection=local.

Création d'un exemple de configuration d'utilisateur SSH réel

Créons un exemple plus réaliste qui démontre comment configurer l'utilisateur SSH pour les hôtes distants. Nous allons créer un nouveau playbook :

cat > ~/project/ansible/remote_user_example.yml << 'EOF'
---
- name: Example of remote user configuration
  hosts: all
  remote_user: admin_user
  
  tasks:
    - name: This task uses the play-level user (admin_user)
      debug:
        msg: "This would run as admin_user"
      
    - name: This task uses a specific user
      debug:
        msg: "This would run as operator_user"
      remote_user: operator_user
      
    - name: This task uses become to elevate privileges
      debug:
        msg: "This would run as the root user"
      become: true
      become_user: root
EOF

Dans ce playbook :

• Nous définissons remote_user: admin_user au niveau du play, ce qui s'applique à toutes les tâches par défaut.
• La deuxième tâche remplace cela par remote_user: operator_user.
• La troisième tâche utilise become: true pour élever les privilèges vers l'utilisateur root.

Cet exemple montre les différents niveaux auxquels vous pouvez configurer l'utilisateur SSH dans Ansible.

Configuration avancée de l'utilisateur SSH et dépannage

Maintenant que nous avons couvert les bases de la définition de l'utilisateur SSH par défaut pour Ansible, explorons quelques techniques avancées et étapes de dépannage.

Utilisation des clés SSH avec Ansible

Lors de la connexion à des hôtes distants, il est recommandé d'utiliser l'authentification par clé SSH au lieu des mots de passe. Voyons comment configurer l'authentification par clé SSH dans Ansible :

cat > ~/project/ansible/ssh_key_example.yml << 'EOF'
---
- name: Example using SSH key authentication
  hosts: all
  remote_user: secure_user
  vars:
    ansible_ssh_private_key_file: ~/.ssh/id_rsa
  
  tasks:
    - name: Show SSH connection details
      debug:
        msg: "Connecting as {{ ansible_user }} using key {{ ansible_ssh_private_key_file }}"
EOF

Dans cet exemple :

• Nous définissons remote_user: secure_user comme utilisateur SSH par défaut.
• Nous spécifions le fichier de clé privée SSH à utiliser avec ansible_ssh_private_key_file.

Définir différents utilisateurs pour différents environnements

Dans des scénarios réels, vous souhaiterez peut-être utiliser différents utilisateurs SSH pour différents environnements (développement, staging, production). Voyons comment y parvenir :

mkdir -p ~/project/ansible/group_vars

Maintenant, créons des fichiers de variables de groupe pour différents environnements :

cat > ~/project/ansible/group_vars/development << 'EOF'
---
ansible_user: dev_user
EOF

cat > ~/project/ansible/group_vars/production << 'EOF'
---
ansible_user: prod_user
ansible_ssh_private_key_file: ~/.ssh/prod_key
EOF

Mettez à jour le fichier d'inventaire pour inclure ces groupes d'environnement :

cat > ~/project/ansible/inventory/hosts << 'EOF'
[webservers]
localhost ansible_connection=local

[development]
dev.example.com

[production]
prod1.example.com
prod2.example.com

[all:vars]
ansible_user=default_user
EOF

Avec cette configuration :

• Les hôtes du groupe development utiliseront l'utilisateur SSH dev_user.
• Les hôtes du groupe production utiliseront l'utilisateur SSH prod_user et une clé SSH spécifique.
• Tous les autres hôtes utiliseront l'utilisateur SSH default_user.

Dépannage de la configuration de l'utilisateur SSH

Si vous rencontrez des problèmes avec la configuration de l'utilisateur SSH dans Ansible, voici quelques étapes de dépannage :

1. Vérifiez l'inventaire interprété par Ansible

Pour voir comment Ansible interprète votre inventaire, y compris toutes les valeurs de variables :

ansible-inventory --list

2. Exécutez Ansible avec une verbosité accrue

L'exécution d'Ansible avec une verbosité accrue peut aider à identifier les problèmes de connexion :

ansible localhost -m ping -vvv

L'option -vvv augmente le niveau de verbosité, affichant des informations détaillées sur le processus de connexion SSH.

3. Testez la connexion SSH manuellement

Vous pouvez tester la connexion SSH manuellement pour vérifier que l'utilisateur et la clé fonctionnent :

ssh -i ~/.ssh/id_rsa username@hostname

4. Vérifiez les erreurs de connexion SSH

Les erreurs de connexion SSH courantes incluent :

• Permission denied (publickey) : Cela indique un problème avec l'authentification par clé SSH.
• Host key verification failed : Cela se produit lorsque la clé d'hôte a changé.
• Connection refused : Cela indique que le service SSH n'est pas en cours d'exécution ou est bloqué par un pare-feu.

5. Créez un playbook de test de configuration Ansible

Créons un playbook simple pour tester notre configuration d'utilisateur SSH :

cat > ~/project/ansible/test_ssh_config.yml << 'EOF'
---
- name: Test SSH user configuration
  hosts: all
  gather_facts: no
  
  tasks:
    - name: Display connection information
      debug:
        msg: |
          Connected to: {{ inventory_hostname }}
          User: {{ ansible_user | default('not set') }}
          SSH Key: {{ ansible_ssh_private_key_file | default('not set') }}
EOF

Exécutez ce playbook pour voir les informations de connexion pour chaque hôte :

ansible-playbook -i inventory/hosts test_ssh_config.yml

Ce playbook vous montrera l'utilisateur SSH et la clé qu'Ansible utilise pour chaque hôte, ce qui peut aider à identifier les problèmes de configuration.

Résumé

Dans ce laboratoire, vous avez appris à configurer l'utilisateur SSH par défaut pour les connexions Ansible en utilisant diverses méthodes. Vous comprenez maintenant comment :

1. Installer et configurer Ansible avec une configuration de base.
2. Configurer l'utilisateur SSH par défaut via le fichier de configuration Ansible.
3. Définir les utilisateurs SSH à différents niveaux : inventaire, playbook et ligne de commande.
4. Vérifier et tester votre configuration d'utilisateur SSH.
5. Dépanner les problèmes de connexion SSH courants.

Ces compétences vous permettront de gérer votre infrastructure plus efficacement avec Ansible, en assurant des connexions sécurisées et fiables à vos serveurs distants. En configurant correctement l'utilisateur SSH pour vos connexions Ansible, vous pouvez mettre en œuvre des flux de travail d'automatisation cohérents dans différents environnements tout en maintenant des pratiques de sécurité appropriées.