Hub de Connaissances DevOps
Hub de Connaissances DevOps

Résoudre rapidement les erreurs « Connection Refused » SSH

Rencontrer une erreur SSH « Connection Refused » peut interrompre la gestion de votre serveur distant. Ce guide complet détaille un dépannage étape par étape, en se concentrant sur les diagnostics critiques côté serveur. Apprenez à vérifier l'état de votre démon SSH, à consulter et configurer les règles de pare-feu (UFW, firewalld), à inspecter les paramètres de `sshd_config`, et à utiliser des tests de connectivité réseau de base. Des commandes pratiques et des conseils exploitables sont fournis pour résoudre rapidement le problème et restaurer un accès sécurisé à vos systèmes, vous assurant de reprendre le contrôle rapidement.

51 vues

Résoudre Rapidement les Erreurs de Connexion SSH Refusée

SSH (Secure Shell) est la colonne vertébrale de la gestion de serveurs à distance, 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 <IP_ADDRESS> port 22: Connection refused peut être un obstacle frustrant, vous empêchant d'accéder à vos systèmes essentiels.

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

Comprendre l'Erreur 'Connexion Refusée'

Lorsque vous recevez une erreur Connection refused (Connexion refusée), 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é. Ceci est différent d'une erreur Connection timed out (Délai de connexion dépassé), où le client n'a pas pu atteindre le serveur du tout, ou d'une erreur No route to host (Pas de route vers l'hôte), où le chemin réseau est rompu.

Le statut "refusé" indique directement un problème 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 qu'il y a une mauvaise configuration au sein du service SSH lui-même.

Causes Courantes de 'Connexion Refusée'

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

  • Démon SSH (sshd) non exécuté : La cause la plus fréquente. Le processus du serveur SSH a peut-être planté, été arrêté ou n'a pas réussi à démarrer 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é, ce qui amène 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 un 'Refusé') : Bien que moins probable pour une erreur "refusée", un problème réseau fondamental pourrait 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, en particulier après des configurations personnalisées ou des modifications du système.

Guide de Dépannage Étape par Étape

Plongeons dans les étapes pratiques pour diagnostiquer et résoudre l'erreur de '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+) :
    bash sudo systemctl status sshd
    Si sshd ne fonctionne pas, la sortie indiquera inactive (dead) ou un statut similaire.

  2. Démarrer le démon SSH :
    Si le statut est inactif, essayez de démarrer le service :
    bash sudo systemctl start sshd

  3. Activer le démarrage du démon SSH au démarrage :
    Pour vous assurer que SSH démarre automatiquement après un redémarrage, activez-le :
    bash sudo systemctl enable sshd

  4. Vérifier les journaux du démon SSH :
    Si sshd ne démarre pas, ses journaux peuvent fournir des indices cruciaux. Pour les systèmes systemd :
    bash sudo journalctl -u sshd --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 la cause 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 :
      bash 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 ALLOWed (autorisé).
    • firewalld :
      bash sudo firewall-cmd --list-all
      Vérifiez les sections services et ports pour ssh ou port 22/tcp.
    • iptables :
      bash 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 :
      bash sudo ufw allow ssh # Autorise le port 22 # Ou, pour un port personnalisé (ex: 2222) : sudo ufw allow 2222/tcp sudo ufw enable # Si UFW est inactif
    • firewalld :
      bash sudo firewall-cmd --permanent --add-service=ssh # Ou, pour un port personnalisé (ex: 2222) : sudo firewall-cmd --permanent --add-port=2222/tcp sudo firewall-cmd --reload
    • iptables :
      L'ajout direct de règles iptables est plus complexe et temporaire, à moins d'être enregistré. Il est généralement recommandé d'utiliser firewalld ou ufw si disponibles. Pour un test rapide (non persistant) :
      bash sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # Vous devrez enregistrer 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 de manière permanente. Vérifiez toujours que vos modifications fonctionnent avant de fermer votre session SSH actuelle, si vous en avez une 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 le refus des connexions.

  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) :
    bash 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é (#), le port par défaut est le port 22.
    • ListenAddress : Si présente, cette directive spécifie les adresses IP sur lesquelles sshd doit écouter. S'il est défini sur une IP interne (par exemple, 127.0.0.1) et que vous vous connectez depuis un réseau externe, la connexion sera refusée. Pour écouter sur toutes les interfaces, il est souvent commenté ou défini sur 0.0.0.0 ou :: (pour IPv6).
    • PermitRootLogin : S'il est défini sur no, vous ne pourrez pas vous connecter en tant que root. Bien qu'il ne s'agisse pas d'un "refus de connexion" au sens strict (c'est souvent un refus de permission après la connexion), cela peut empêcher les tentatives de connexion réussies.
    • PasswordAuthentication : S'il est 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 impérativement redémarrer le service SSH pour qu'elles prennent effet :
    bash 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. Pinger le Serveur :
    Depuis votre machine cliente, essayez de pinger l'adresse IP ou le nom d'hôte du serveur :
    bash ping <SERVER_IP_ADDRESS_OR_HOSTNAME>
    Si le ping échoue (100 % de perte de paquets), 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 vérifier si le port est ouvert et en écoute du point de vue du client :
    ```bash
    # En utilisant netcat (nc)
    nc -zv 22

    En utilisant telnet

    telnet 22
    `` SincafficheConnection refusedou sitelnet` se ferme immédiatement, cela confirme que le serveur rejette activement la connexion 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 pourraient empêcher sshd de fonctionner correctement, en particulier si vous utilisez un port SSH non standard.

  1. Vérifier le Statut de SELinux :
    bash sestatus
    Si SELinux est en mode enforcing (application stricte), vous devrez peut-être ajuster ses politiques pour autoriser sshd sur un port personnalisé.
    Par exemple, pour autoriser le port 2222 pour SSH :
    bash 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 sur CentOS/RHEL).

  2. Vérifier le Statut d'AppArmor :
    bash sudo aa status
    Si AppArmor est en mode enforcing, examinez ses journaux (/var/log/syslog ou dmesg) pour toute restriction liée à sshd.

Étape 6 : Examiner les Journaux du Serveur (À Nouveau)

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 pour comprendre ce que le serveur rencontre.

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

Recherchez les messages indiquant pourquoi le service ne démarre pas, pourquoi les connexions sont interrompues, ou toute autre information pertinente.

Bonnes Pratiques pour Prévenir les Problèmes Futurs

  • Mettre à jour Régulièrement Votre OS : Maintenez le système d'exploitation et les paquets de votre serveur, y compris openssh-server, à jour.
  • Tester les Règles du Pare-feu : Après avoir implémenté ou modifié des règles de pare-feu, testez-les toujours immédiatement.
  • Sauvegarder sshd_config : Avant d'apporter des modifications à /etc/ssh/sshd_config, faites-en une sauvegarde (sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak).
  • Utiliser 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.
  • Surveiller les Journaux : Examinez régulièrement les journaux auth.log ou secure pour détecter toute activité inhabituelle ou erreur persistante.

Conclusion

L'erreur 'Connexion Refusée', bien que frustrante, est généralement simple à résoudre en vérifiant systématiquement le statut du démon SSH, les règles du pare-feu et le fichier sshd_config. En suivant les étapes décrites dans ce guide, vous pouvez diagnostiquer efficacement la cause première et restaurer votre accès distant sécurisé. N'oubliez pas d'appliquer toujours les changements avec prudence et de vérifier la fonctionnalité pour éviter de vous retrouver bloqué hors de votre serveur.

Grâce à ces techniques de dépannage, vous serez bien équipé pour résoudre les problèmes de connexion SSH et maintenir un contrôle fluide sur vos systèmes distants. Bonne utilisation de SSH !