sshpass avec Ansible : automatiser un mot de passe (et pourquoi l'éviter)

Depuis le tout premier TP de cette formation, on tape régulièrement -k en ligne de commande pour qu’Ansible nous demande le mot de passe SSH de façon interactive. Ça fonctionne très bien… tant qu’un humain est là pour taper le mot de passe à chaque fois. Mais que faire si vous devez scripter cette étape, par exemple pour déployer automatiquement une clé publique sur toute une flotte de serveurs fraîchement créés, sans encore aucune clé en place ? C’est le rôle de sshpass.

Le problème concret

Reprenez le tout premier geste qu’on répète depuis le début de cette formation à chaque nouveau TP :

ssh root@nrd-web1
nano .ssh/authorized_keys
# Coller la clé publique à la main

Sur un seul serveur, ça prend dix secondes. Sur vingt serveurs fraîchement provisionnés, sans encore aucune clé SSH déployée, c’est vingt allers-retours manuels — exactement le genre de tâche répétitive que cette formation cherche à éliminer depuis la leçon 1.1.

Installer `sshpass`

apt install sshpass

Utiliser `sshpass` avec Ansible

sshpass permet de fournir un mot de passe SSH non interactivement, en le passant en argument plutôt qu’en le tapant au clavier :

Ou, de façon encore plus directe, en combinant avec la variable d’environnement SSHPASS :

export SSHPASS='formation'
sshpass -e ansible-playbook playbook_bootstrap.yaml -i inventaire.yaml -u root

Concrètement, ça permet d’écrire un petit script de bootstrap qui, sur une flotte de machines toutes fraîches (comme les conteneurs de nos labs, justement), va déployer la clé publique de tout le monde d’un coup, sans intervention manuelle :

# playbook_bootstrap_ssh.yaml
---
- name: Déployer la clé SSH sur des machines fraîches
  hosts: all
  gather_facts: no

  tasks:
    - name: Copier la clé publique du nœud de contrôle
      ansible.posix.authorized_key:
        user: root
        state: present
        key: "{{ lookup('file', '~/.ssh/id_ed25519.pub') }}"

export SSHPASS='formation'
sshpass -e ansible-playbook playbook_bootstrap_ssh.yaml -i inventaire.yaml -u root

Une fois ce playbook passé, toutes les machines acceptent désormais votre clé SSH — plus jamais besoin de sshpass ni de mot de passe pour elles.

Pourquoi ce n’est pas la bonne pratique en dehors d’un lab

Trois problèmes concrets, et c’est pour ça que cette leçon porte bien son sous-titre :

1. Le mot de passe traîne en clair. Que ce soit dans une variable SSHPASS visible via env, dans l’historique de votre shell (history), ou dans les logs d’un pipeline CI/CD, un mot de passe passé de cette façon est exposé bien plus largement qu’un simple prompt interactif.

2. Ça encourage les mots de passe partagés. sshpass suppose un mot de passe identique (ou connu à l’avance) sur toute la flotte — exactement le genre de pratique qu’on cherche à éviter en administration système sérieuse.

3. Ça masque le vrai problème : l’authentification par clé n’est pas encore en place. sshpass est un contournement, pas une solution. Une fois les clés déployées (via authorized_key, vu en 7.3), il n’y a plus aucune raison de continuer à s’appuyer sur un mot de passe.

Le bon usage : un pont temporaire, jamais une destination

Le seul cas légitime pour sshpass avec Ansible, c’est exactement ce qu’on vient de voir : le tout premier contact avec une machine fraîchement créée, qui n’a encore aucune clé autorisée. Une fois ce pont franchi et la clé déployée, sshpass n’a plus sa place dans votre flux de travail habituel.

⚠️ On a d’ailleurs déjà fait exactement ça, sans le nommer, dans chaque TP de cette formation : ssh-keygen + dépôt manuel de la clé, à chaque fois que le lab reparlait de zéro. sshpass permet simplement d’automatiser ce geste plutôt que de le refaire à la main à chaque session.

Ce qu’il faut retenir

sshpass permet de fournir un mot de passe SSH de façon non interactive, utile pour scripter un premier contact avec des machines fraîches.
Ce n’est jamais une solution pour de la production : mot de passe exposé dans l’historique, les process, ou les logs CI.
Le vrai objectif reste toujours de déployer une clé SSH (authorized_key, vu en 7.3) le plus tôt possible, et d’abandonner sshpass juste après.

Dans la prochaine leçon, on termine la gestion du personnel avec les droits : sudoers, et comment accorder des privilèges élevés sans donner le mot de passe root à tout le monde.