Résoudre rapidement les erreurs de connexion SSH refusée

SSH (Secure Shell) est le pilier de la gestion de serveurs distants, permettant une communication sécurisée et chiffrée entre votre machine locale et un serveur distant. Cependant, rencontrer une erreur ssh: connect to host <ADRESSE_IP> port 22: Connection refused peut être un obstacle frustrant, vous empêchant d'accéder à vos systèmes cruciaux.

Cet article fournit un guide complet, étape par étape, pour diagnostiquer et résoudre l'erreur courante 'Connexion refusée'. Nous explorerons les principaux coupables, des démons SSH inactifs aux pare-feu mal configurés et aux paramètres de serveur incorrects, vous dotant des connaissances et des commandes pour retrouver rapidement l'accès à vos serveurs.

Comprendre l'erreur 'Connexion refusée'

Lorsque vous recevez une erreur Connection refused, cela signifie que votre client SSH a bien atteint le serveur distant, mais que le serveur a explicitement refusé la connexion sur le port spécifié. Cela se distingue d'une erreur Connection timed out (où le client n'a pas pu atteindre le serveur du tout) ou d'une erreur No route to host (où le chemin réseau est rompu).

Le statut "refusé" pointe directement vers un problème du côté serveur qui empêche activement le service SSH d'accepter les connexions. Cela implique généralement que le démon SSH ne fonctionne pas, qu'un pare-feu bloque la connexion, ou une mauvaise configuration au sein du service SSH lui-même.

Causes courantes de 'Connexion refusée'

Plusieurs facteurs peuvent entraîner un refus de connexion SSH. Les comprendre aide à affiner le processus de dépannage :

• Démon SSH (sshd) ne fonctionne pas : La cause la plus courante. Le processus du serveur SSH a peut-être planté, a été arrêté ou n'a pas démarré au démarrage.
• Pare-feu bloquant le port 22 (ou un port personnalisé) : Le pare-feu du serveur (par exemple, UFW, firewalld, iptables) empêche les connexions entrantes sur le port SSH.
• Configuration incorrecte du démon SSH : Le fichier sshd_config peut être mal configuré, amenant le démon SSH à écouter sur un port différent, une mauvaise interface réseau, ou à refuser les connexions pour des utilisateurs/méthodes spécifiques.
• Problèmes de connectivité réseau (moins courants pour 'Refusé') : Bien que moins probable pour une erreur "refusée", un problème réseau fondamental peut parfois se manifester de manière inattendue.
• Restrictions SELinux ou AppArmor : Des améliorations de sécurité comme SELinux ou AppArmor peuvent empêcher sshd de fonctionner correctement, surtout après des configurations personnalisées ou des modifications système.

Guide de dépannage étape par étape

Plongeons dans les étapes pratiques pour diagnostiquer et corriger l'erreur 'Connexion refusée'.

Étape 1 : Vérifier le statut du démon SSH sur le serveur

La première chose à vérifier est si le démon du serveur SSH (sshd) est réellement en cours d'exécution sur votre machine distante. Vous aurez généralement besoin d'un accès console (par exemple, via la console d'un fournisseur cloud ou une connexion physique) pour effectuer ces vérifications si SSH est totalement inaccessible.

1. Vérifier le statut du démon SSH : Sur la plupart des distributions Linux modernes (celles utilisant systemd comme Ubuntu, CentOS 7+, Debian 8+) :

   sudo systemctl status sshd
   

Sur Debian/Ubuntu, le service peut être nommé ssh :

sudo systemctl status ssh ``` Si sshd ne fonctionne pas, la sortie indiquera inactive (dead) ou un statut similaire.

1. Démarrer le démon SSH : Si le statut est inactif, essayez de démarrer le service :

   sudo systemctl start sshd
   

Ou sur Debian/Ubuntu :

sudo systemctl start ssh ```

1. Activer le démon SSH au démarrage : Pour garantir que SSH démarre automatiquement après un redémarrage, activez-le :

   sudo systemctl enable sshd
   

Ou sur Debian/Ubuntu :

sudo systemctl enable ssh ```

1. Vérifier les journaux du démon SSH : Si sshd ne parvient pas à démarrer, ses journaux peuvent fournir des indices cruciaux. Pour les systèmes systemd :

   sudo journalctl -u sshd --since "10 minutes ago"
   

Ou, si votre distribution utilise l'unité ssh :

sudo journalctl -u ssh --since "10 minutes ago" Alternativement, vérifiez les journaux d'authentification généraux : bash sudo tail -f /var/log/auth.log # Ou pour RHEL/CentOS : sudo tail -f /var/log/secure ```

Étape 2 : Vérifier les règles du pare-feu

Un pare-feu côté serveur est souvent le coupable des refus de connexion. Il peut bloquer le port SSH par défaut (22) ou un port personnalisé que vous essayez d'utiliser. Vous devez vous assurer que le pare-feu autorise les connexions entrantes sur le port SSH.

1. Identifier votre pare-feu : Les pare-feu courants incluent :

   • UFW (Uncomplicated Firewall) : Courant sur Ubuntu/Debian.
   • firewalld : Courant sur CentOS/RHEL 7+.
   • iptables : Le pare-feu sous-jacent pour Linux, configuré directement ou via des interfaces.

2. Vérifier le statut et les règles du pare-feu :

   • UFW :

     sudo ufw status verbose
     

     Recherchez les règles autorisant le trafic sur le port 22 (ou votre port SSH personnalisé). Si SSH est listé, assurez-vous qu'il est ALLOWé.
   • firewalld :

     sudo firewall-cmd --list-all
     

     Vérifiez les sections services et ports pour ssh ou port 22/tcp.
   • iptables :

     sudo iptables -L -v -n
     

     Cette sortie peut être complexe. Recherchez les règles DROP ou REJECT liées à tcp dpt:22 (ou votre port personnalisé) dans la chaîne INPUT.

3. Autoriser le port SSH à travers le pare-feu :

   • UFW :

     sudo ufw allow ssh        # Autorise le port 22
     # Ou, pour un port personnalisé (par exemple, 2222) :
     sudo ufw allow 2222/tcp
     sudo ufw enable           # Si UFW est inactif
     

   • firewalld :

     sudo firewall-cmd --permanent --add-service=ssh
     # Ou, pour un port personnalisé (par exemple, 2222) :
     sudo firewall-cmd --permanent --add-port=2222/tcp
     sudo firewall-cmd --reload
     

   • iptables : Ajouter des règles iptables directement est plus complexe et temporaire sauf si elles sont sauvegardées. Il est généralement recommandé d'utiliser firewalld ou ufw si disponibles. Pour un test rapide (non persistant) :

     sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
     sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
     # Vous devrez sauvegarder ces règles si vous voulez qu'elles persistent après les redémarrages.
     

   Avertissement : Soyez prudent lors de la modification des règles de pare-feu, surtout lorsque vous vous connectez en SSH à un serveur distant. Des règles incorrectes peuvent vous verrouiller définitivement. Vérifiez toujours que vos modifications fonctionnent avant de fermer votre session SSH actuelle, si vous en avez une d'ouverte.

Étape 3 : Vérifier la configuration SSH (sshd_config)

Le fichier de configuration du démon SSH (/etc/ssh/sshd_config) dicte le fonctionnement du service. Des erreurs de configuration ici peuvent entraîner des refus de connexion.

1. Localiser sshd_config : Le fichier de configuration principal se trouve généralement à /etc/ssh/sshd_config.

2. Inspecter les paramètres clés : Ouvrez le fichier avec un éditeur de texte (par exemple, nano, vi) :

   sudo nano /etc/ssh/sshd_config
   

   Recherchez les directives suivantes :

   • Port : Spécifie le port sur lequel sshd écoute. Assurez-vous qu'il correspond au port auquel vous essayez de vous connecter depuis votre client. S'il est commenté (#), il est par défaut sur le port 22.
   • ListenAddress : Si présent, spécifie les adresses IP sur lesquelles sshd doit écouter. Si elle est définie sur une IP interne (par exemple, 127.0.0.1) et que vous vous connectez depuis un réseau externe, elle refusera la connexion. Pour écouter sur toutes les interfaces, elle est souvent commentée ou définie sur 0.0.0.0 ou :: (pour IPv6).
   • PermitRootLogin : Si défini sur no, vous ne pourrez pas vous connecter en tant que root. Bien que ce ne soit pas un "refus de connexion" au sens strict (c'est souvent une autorisation refusée après la connexion), cela peut empêcher les tentatives de connexion réussies.
   • PasswordAuthentication : Si défini sur no, l'authentification par mot de passe est désactivée, nécessitant une authentification par clé.

   Conseil : Après avoir apporté des modifications à sshd_config, vous devez redémarrer le service SSH pour qu'elles prennent effet :

   sudo systemctl restart sshd
   

Étape 4 : Connectivité réseau (vérification de base)

Bien qu'un "refus de connexion" signifie généralement que le serveur a été atteint, il est toujours bon de confirmer rapidement la joignabilité réseau de base depuis votre machine cliente vers l'adresse IP du serveur.

1. Ping du serveur : Depuis votre machine cliente, essayez de pinguer l'adresse IP ou le nom d'hôte du serveur :

   ping <ADRESSE_IP_OU_NOM_D_HOTE_DU_SERVEUR>
   

   Si le ping échoue (perte de paquets à 100 %), vous avez un problème réseau plus fondamental (par exemple, IP incorrecte, serveur hors ligne, problème de routage réseau) qui doit être résolu avant SSH.

2. Utiliser nc ou telnet (depuis le client) : Pour tester si le port est ouvert et à l'écoute du point de vue du client :

   # Utilisation de netcat (nc)
   nc -zv <ADRESSE_IP_DU_SERVEUR> 22
   
   # Utilisation de telnet
   telnet <ADRESSE_IP_DU_SERVEUR> 22
   

   Si nc affiche Connection refused ou que telnet se ferme immédiatement, cela confirme que le serveur rejette activement sur ce port, ce qui renvoie au démon SSH ou au pare-feu.

Étape 5 : Vérifier SELinux ou AppArmor (Avancé)

Dans certains environnements renforcés, ou après des configurations personnalisées, SELinux (Security-Enhanced Linux) ou AppArmor peuvent empêcher sshd de fonctionner correctement, surtout si vous utilisez un port SSH non standard.

1. Vérifier le statut de SELinux :

   sestatus
   

   Si SELinux est enforcing, vous devrez peut-être ajuster ses politiques pour autoriser sshd sur un port personnalisé. Par exemple, pour autoriser le port 2222 pour SSH :

   sudo semanage port -a -t ssh_port_t -p tcp 2222
   sudo systemctl restart sshd
   

   (Installez semanage s'il n'est pas disponible : sudo apt install policycoreutils-python-utils sur Debian/Ubuntu, sudo yum install policycoreutils-python-utils ou le paquet correspondant pour votre version de la famille RHEL).

2. Vérifier le statut d'AppArmor :

   sudo aa status
   

   Si AppArmor est enforcing, examinez ses journaux (/var/log/syslog ou dmesg) pour tout refus lié à sshd.

Étape 6 : Revoir les journaux du serveur (encore)

Après avoir tenté les étapes précédentes, vérifiez toujours à nouveau les journaux du serveur pour tout nouveau message d'erreur lié à sshd. C'est votre source de vérité ultime sur ce que le serveur rencontre.

• sudo journalctl -u sshd
• sudo tail -f /var/log/auth.log (ou /var/log/secure)

Recherchez des messages indiquant pourquoi le service pourrait ne pas démarrer, pourquoi les connexions sont abandonnées, ou toute autre information pertinente.

Meilleures pratiques pour éviter les problèmes futurs

• Mettez régulièrement à jour votre OS : Maintenez le système d'exploitation de votre serveur et les paquets, y compris openssh-server, à jour.
• Testez les règles de pare-feu : Après avoir implémenté ou modifié des règles de pare-feu, testez-les toujours immédiatement.
• Sauvegardez sshd_config : Avant d'apporter des modifications à /etc/ssh/sshd_config, faites une sauvegarde (sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak).
• Utilisez une console de gestion : Pour les instances cloud, sachez comment accéder à la console du serveur (par exemple, AWS EC2 Serial Console, Google Cloud Console) pour dépanner les problèmes réseau lorsque SSH est indisponible.
• Surveillez les journaux : Examinez régulièrement les journaux auth.log ou secure pour toute activité inhabituelle ou erreurs persistantes.

Conclusion finale

Une erreur de connexion SSH refusée signifie généralement que le serveur est joignable mais que rien n'accepte votre connexion sur ce port. Vérifiez le nom du service SSH pour votre distribution, confirmez que le port écoute, ouvrez le pare-feu, validez sshd_config, et lisez les journaux avant d'apporter des modifications plus importantes. Si vous avez encore une session ouverte qui fonctionne, gardez-la ouverte jusqu'à ce qu'une nouvelle connexion réussisse.