Contactez-nous

Problèmes de connectivité SSH (authentification, hôte non joignable)

Diagnostiquez et solutionnez les erreurs de connectivité SSH dans Ansible, incluant les échecs d'authentification par clé, les hôtes non joignables et les configurations utilisateur incorrectes.

La connexion SSH : fondation de la communication Ansible

Ansible, dans sa configuration par défaut, repose exclusivement sur le protocole Secure Shell (SSH) pour communiquer avec les noeuds gérés (managed nodes). Si la connexion SSH entre le noeud de contrôle Ansible et une machine distante ne peut être établie, aucune tâche d'automatisation ne pourra être exécutée sur cette dernière. Les problèmes de connectivité SSH sont donc une source fréquente d'échecs, en particulier lors de la mise en place initiale d'un environnement Ansible ou de l'ajout de nouveaux hôtes.

Ces problèmes peuvent se manifester de diverses manières : échecs d'authentification, hôtes signalés comme non joignables (unreachable), ou timeouts de connexion. Comprendre les causes sous-jacentes de ces erreurs et savoir comment les diagnostiquer est essentiel pour assurer le bon fonctionnement de vos playbooks.

Cette section explore les scénarios de problèmes SSH les plus courants que vous pourriez rencontrer avec Ansible, des erreurs de configuration des clés SSH aux problèmes de réseau ou de service sur les hôtes distants, et fournit des méthodes pour les identifier et les résoudre.

Diagnostiquer les messages d'erreur SSH courants d'Ansible

Lorsqu'Ansible ne parvient pas à se connecter à un hôte, il retourne généralement un message d'erreur assez explicite dans sa sortie. L'un des messages les plus courants est :

fatal: [nom_de_l_hote]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: ssh: connect to host nom_de_l_hote port 22: Connection timed out", "unreachable": true}
Ce message indique un "Connection timed out", signifiant que le noeud de contrôle n'a pas pu établir une connexion TCP avec le port SSH (généralement le port 22) de l'hôte distant dans le délai imparti. Les causes peuvent être multiples : l'hôte est éteint, un pare-feu bloque la connexion (sur le noeud de contrôle, sur l'hôte distant, ou entre les deux), ou il y a un problème de routage réseau.

Un autre type d'erreur fréquent concerne l'authentification :

fatal: [nom_de_l_hote]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: Permission denied (publickey,password).", "unreachable": true}
Le message "Permission denied (publickey,password)" indique que le serveur SSH distant a refusé la tentative de connexion. Cela signifie généralement que l'authentification par clé publique n'a pas fonctionné et que l'authentification par mot de passe est soit désactivée, soit a également échoué (ou n'a pas été tentée si vous n'avez pas utilisé l'option --ask-pass).

D'autres variations peuvent inclure des problèmes de résolution DNS si vous utilisez des noms d'hôtes (par exemple, "ssh: Could not resolve hostname nom_de_l_hote: Name or service not known") ou des erreurs liées à la vérification de la clé d'hôte SSH si elle a changé.

Vérifications et solutions pour les problèmes d'hôte non joignable

Si Ansible signale un hôte comme "UNREACHABLE" avec un timeout ou une incapacité à résoudre le nom :

  • Vérification de base du réseau : Commencez par un simple ping nom_de_l_hote_ou_IP depuis le noeud de contrôle. Si le ping ne fonctionne pas, le problème est probablement d'ordre réseau (hôte éteint, problème de câble, de switch, de routage, ou pare-feu bloquant ICMP).
  • Résolution DNS : Si vous utilisez un nom d'hôte, vérifiez qu'il se résout correctement en adresse IP avec nslookup nom_de_l_hote ou dig nom_de_l_hote. Si ce n'est pas le cas, corrigez vos configurations DNS ou utilisez l'adresse IP directement dans l'inventaire Ansible.
  • Service SSHD sur l'hôte distant : Assurez-vous que le service SSH (généralement nommé sshd ou ssh) est en cours d'exécution sur l'hôte distant. Connectez-vous à la console de l'hôte (si possible) et vérifiez son statut (par exemple, systemctl status sshd sur les systèmes systemd).
  • Pare-feu : Vérifiez les règles de pare-feu tant sur le noeud de contrôle que sur l'hôte distant, ainsi que sur tout équipement réseau intermédiaire. Le port SSH (par défaut 22/TCP) doit être ouvert pour les connexions entrantes sur l'hôte distant depuis l'IP du noeud de contrôle. Des outils comme telnet nom_de_l_hote_ou_IP 22 ou nc -zv nom_de_l_hote_ou_IP 22 depuis le noeud de contrôle peuvent aider à vérifier si le port est accessible.
  • Inventaire Ansible : Vérifiez que l'adresse IP ou le nom d'hôte spécifié pour ansible_host dans votre fichier d'inventaire est correct.

Résoudre les échecs d'authentification SSH

Si le problème est une "Permission denied", cela pointe vers un souci d'authentification. Ansible privilégie l'authentification par clé SSH, qui est plus sécurisée et pratique pour l'automatisation que les mots de passe.

  • Configuration des clés SSH : C'est la cause la plus fréquente. Assurez-vous que :
    1. La clé publique (~/.ssh/id_rsa.pub ou similaire) de l'utilisateur exécutant Ansible sur le noeud de contrôle a été correctement copiée dans le fichier ~/.ssh/authorized_keys de l'utilisateur cible sur l'hôte distant (celui spécifié par ansible_user ou l'utilisateur par défaut).
    2. Les permissions sur le répertoire .ssh (devrait être 700) et sur le fichier authorized_keys (devrait être 600 ou 644) sur l'hôte distant sont correctes. Des permissions trop ouvertes peuvent empêcher l'authentification par clé.
    3. La clé privée correspondante sur le noeud de contrôle est accessible et a les bonnes permissions (600).
    4. Si votre clé privée est protégée par une passphrase, vous devrez utiliser ssh-agent pour la mettre en cache ou fournir la passphrase à Ansible (ce qui est moins recommandé pour l'automatisation).
    Utilisez la commande ssh-copy-id utilisateur@hote_distant pour copier facilement votre clé publique.
  • Utilisateur de connexion (ansible_user) : Vérifiez que l'utilisateur spécifié dans votre inventaire via la variable ansible_user (ou l'utilisateur par défaut avec lequel Ansible tente de se connecter) existe bien sur l'hôte distant et est autorisé à se connecter via SSH. Par défaut, Ansible essaiera de se connecter avec le même nom d'utilisateur que celui qui exécute la commande ansible ou ansible-playbook.
  • Configuration du serveur SSHD : Sur l'hôte distant, le fichier de configuration du serveur SSH (souvent /etc/ssh/sshd_config) doit autoriser l'authentification par clé publique (PubkeyAuthentication yes) et spécifier le bon chemin pour le fichier des clés autorisées (AuthorizedKeysFile .ssh/authorized_keys). Si vous avez modifié ce fichier, n'oubliez pas de redémarrer le service SSHD.
  • Tester manuellement la connexion SSH : Une étape de débogage cruciale est de tenter une connexion SSH manuelle depuis le noeud de contrôle vers l'hôte distant avec le même utilisateur et la même clé que ceux qu'Ansible utiliserait :
    ssh -i /chemin/vers/cle_privee utilisateur_ansible@hote_distant -v
    L'option -v (pour verbose) vous donnera des détails sur le processus d'authentification et aidera à identifier où il échoue.
  • Utilisation de --ask-pass (-k) : Si vous débutez ou si les clés SSH ne sont pas encore configurées, vous pouvez utiliser l'option -k avec ansible ou ansible-playbook pour qu'Ansible vous demande le mot de passe de connexion SSH. Ce n'est pas une solution à long terme pour l'automatisation mais peut aider à valider d'autres aspects de la configuration.

Autres considérations et débogage avancé

Problèmes de become (escalade de privilèges) : Si la connexion SSH réussit mais que les tâches échouent avec des erreurs de permission, le problème peut venir de la configuration de become (sudo). Assurez-vous que l'utilisateur ansible_user a les droits sudo nécessaires sur l'hôte distant et qu'Ansible est configuré pour utiliser become: yes. Si sudo demande un mot de passe, vous devrez utiliser --ask-become-pass (-K) ou configurer sudo pour ne pas demander de mot de passe à cet utilisateur pour les commandes exécutées par Ansible (configuration `NOPASSWD` dans `sudoers`).Verbosity d'Ansible : Lorsque vous déboguez des problèmes SSH, augmenter la verbosité d'Ansible avec -v, -vv, ou -vvv peut être très utile. A des niveaux de verbosité élevés, Ansible affichera les commandes SSH exactes qu'il tente d'exécuter, y compris les options et les chemins des clés, ce qui peut révéler des erreurs de configuration. Par exemple :
ansible mon_hote -m ping -vvv

En abordant méthodiquement ces points de vérification, vous devriez être en mesure de résoudre la grande majorité des problèmes de connectivité SSH rencontrés avec Ansible.