Ansible par la pratique (4) – Authentification

Voici le quatrième article de la formation Ansible. Dans mon précédent article, nous avons vu de près les différentes manières d’installer Ansible sur le Control Host. Aujourd’hui, nous allons nous intéresser aux machines sur lesquelles nous voulons nous acquitter des tâches administratives, à savoir les Target Hosts.

Authentification sur les Target Hosts

Pour commencer, nous allons nous poser une série de questions :

• Quel compte utilisateur du ou des Target Hosts est joignable depuis l’extérieur via SSH ?
• Quelle méthode d’authentification sera utilisée ? L’authentification par clé SSH sera le meilleur choix.
• Une fois qu’Ansible s’est authentifié, est-ce qu’on dispose déjà des droits root ?
• Est-ce qu’il faut augmenter les droits ? Si oui, est-ce qu’on utilise su ou sudo ?

Notre labo constitué d’une panoplie de box Vagrant nous offre un environnement assez homogène :

• Chaque système est accessible via le compte vagrant avec le mot de passe vagrant.
• L’élévation des droits s’effectue avec sudo.

Un peu de pratique

Placez-vous dans le répertoire du deuxième atelier pratique :

$ cd ~/formation-ansible/atelier-02

Voici les quatre machines virtuelles de cet atelier :

Démarrez les VM :

$ vagrant up

Connectez-vous au Control Host :

$ vagrant ssh ansible

Ansible est déjà installé sur cette machine :

$ type ansible
ansible is /usr/bin/ansible

Notre environnement ne fournit pas de résolution DNS. Étant donné qu’il vaut mieux travailler avec des noms d’hôtes qu’avec des adresses IP, nous allons éditer le fichier /etc/hosts du Control Host. La VM fournit les éditeurs de texte vim et nano à cet effet :

# /etc/hosts
127.0.0.1    localhost.localdomain  localhost
10.23.45.10  ansible.sandbox.lan    ansible
10.23.45.20  rocky.sandbox.lan      rocky
10.23.45.30  debian.sandbox.lan     debian
10.23.45.40  suse.sandbox.lan       suse

Ce n’est pas une mauvaise idée de tester la connectivité de base de nos VM :

$ for HOST in rocky debian suse; do ping -c 1 -q $HOST; done
PING rocky.sandbox.lan (10.23.45.20) 56(84) bytes of data.
1 packets transmitted, 1 received, 0% packet loss, time 0ms
PING debian.sandbox.lan (10.23.45.30) 56(84) bytes of data.
1 packets transmitted, 1 received, 0% packet loss, time 0ms
PING suse.sandbox.lan (10.23.45.40) 56(84) bytes of data.
1 packets transmitted, 1 received, 0% packet loss, time 0ms

Je vais d’abord collecter les clés SSH publiques des Target Hosts :

$ ssh-keyscan -t rsa rocky debian suse >> .ssh/known_hosts
# suse:22 SSH-2.0-OpenSSH_8.4
# rocky:22 SSH-2.0-OpenSSH_8.7
# debian:22 SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u2

Si j’essaie de me connecter successivement à tous mes Target Hosts depuis le Control Host, je m’aperçois que l’hôte rocky pose problème :

$ ssh rocky
vagrant@rocky: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Cela tient du fait que la box Vagrant de Rocky Linux interdit la connexion SSH par mot de passe dans sa configuration par défaut. Je dois donc me connecter à cette box depuis Vagrant et reconfigurer SSH :

$ exit
$ vagrant ssh rocky
$ sudo vim /etc/ssh/sshd_config
...
PasswordAuthentication yes
#PermitEmptyPasswords no
#PasswordAuthentication no
...
$ sudo systemctl reload sshd
$ exit
$ vagrant ssh ansible

Partant de là, je peux mettre en place l’authentification par clé SSH depuis le Control Host. Je génère une paire de clés SSH en acceptant toutes les options par défaut :

$ ssh-keygen 
Generating public/private rsa key pair.
Enter file in which to save the key (/home/vagrant/.ssh/id_rsa): [Entrée]
Enter passphrase (empty for no passphrase): [Entrée]
Enter same passphrase again: [Entrée]
Your identification has been saved in /home/vagrant/.ssh/id_rsa
Your public key has been saved in /home/vagrant/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:1ll42oV6A43V9nyKokliTTSn1hW8UTj6LAYbdjkZWx4 vagrant@ansible
The key's randomart image is:
+---[RSA 3072]----+
|           .o=.  |
|        o o=E.o  |
|       . =+X=*.o |
|        B.OOo.  +|
|       =S==++. ..|
|      o.+ +.+..  |
|     . o + o     |
|        o        |
|                 |
+----[SHA256]-----+

Je distribue la clé publique sur mes Target Hosts en fournissant à chaque fois le mot de passe vagrant :

$ ssh-copy-id vagrant@rocky
...
vagrant@rocky's password: *******
Number of key(s) added: 1
$ ssh-copy-id vagrant@debian
...
vagrant@debian's password: *******
Number of key(s) added: 1
$ ssh-copy-id vagrant@suse
...
vagrant@suse's password: *******
Number of key(s) added: 1

Un premier test sans configuration

Un ping Ansible nous permet de tester le bon fonctionnement de l’authentification sur les Target Hosts :

$ ansible all -i debian,rocky,suse -u vagrant -m ping
debian | SUCCESS => ...
rocky  | SUCCESS => ...
suse   | SUCCESS => ...

Ne vous laissez pas perturber par un avertissement du genre [WARNING]: Platform linux on host suse is using the discovered Python interpreter at /usr/bin/python3.6. En langage tam-tam, cela signifie que l’hôte en question n’est doté que d’un interpréteur Python minimal. Nous verrons cela en temps et en heure.

L’option -u vagrant n’est pas vraiment nécessaire ici, étant donné que le compte utilisateur local vagrant est identique au compte utilisateur sur la cible :

$ ansible all -i debian,rocky,suse -m ping
debian | SUCCESS => ...
rocky  | SUCCESS => ...
suse   | SUCCESS => ...

En dehors de l’avertissement sur l’interpréteur Python, on peut dire que l’opération est un succès et que tout fonctionne comme prévu.

Quittez le Control Host :

$ exit

Supprimez toutes les VM :

$ vagrant destroy -f

Exercice

Placez-vous dans le répertoire du troisième atelier pratique :

$ cd ~/formation-ansible/atelier-03

Voici les quatre machines virtuelles Ubuntu 20.04 de cet atelier :

Démarrez les VM :

$ vagrant up

Connectez-vous au Control Host :

$ vagrant ssh control

Ansible est déjà installé sur cette machine :

$ type ansible
ansible is /usr/bin/ansible

Faites le nécessaire pour réussir un ping Ansible comme ceci :

$ ansible all -i target01,target02,target03 -m ping
target03 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}
target02 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}
target01 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}

Lire la suite : Direnv

La rédaction de cette documentation demande du temps et des quantités significatives de café espresso. Vous appréciez ce blog ? Offrez un café au rédacteur en cliquant sur la tasse.