Dépannage des erreurs SSH courantes : Connexion refusée et Permission refusée

Secure Shell (SSH) est la pierre angulaire de l'administration système à distance, offrant une communication chiffrée pour accéder aux serveurs. Cependant, la rencontre d'erreurs de connexion peut stopper immédiatement la productivité. Les deux erreurs les plus courantes et frustrantes rencontrées par les utilisateurs sont "Connexion refusée" et "Permission refusée".

Ce guide vous guidera à travers une approche systématique pour diagnostiquer et résoudre ces problèmes. En comprenant les causes typiques – allant des obstructions réseau aux configurations d'authentification incorrectes – vous pourrez rapidement restaurer un accès sécurisé à vos machines distantes. Nous couvrirons les vérifications essentielles, de la vérification de l'état du serveur au débogage des mécanismes d'authentification.

Comprendre les erreurs : Refusée vs. Refusée

Il est crucial de différencier les deux messages d'erreur principaux, car ils indiquent des causes profondes très différentes :

Connexion refusée : Cela signifie généralement que la connexion réseau a atteint le serveur, mais que rien n'était à l'écoute sur le port spécifié, ou que le système d'exploitation a activement rejeté la tentative de connexion.
Permission refusée : Cela implique que le service SSH (sshd) a bien reçu la demande de connexion, mais que la tentative d'authentification (mot de passe ou clé) a échoué en raison de la configuration du serveur.

Partie 1 : Dépannage de la "Connexion refusée"

L'erreur "Connexion refusée" (souvent affichée comme ssh: connect to host <hostname> port 22: Connection refused) indique généralement un problème du côté serveur empêchant le démon d'accepter les connexions entrantes.

1. Vérifier l'état du démon SSH (sshd)

La cause la plus fréquente d'un refus est que le processus du serveur SSH n'est pas en cours d'exécution ou a planté.

Étapes à suivre (sur le serveur distant) :

Vérifiez l'état du service en utilisant systemctl (courant sur les distributions Linux modernes) :

systemctl status sshd

Si l'état indique inactive ou failed, démarrez le service :

sudo systemctl start sshd
# L'activer pour qu'il démarre automatiquement au démarrage
sudo systemctl enable sshd

2. Vérifier le port d'écoute et la configuration

Par défaut, SSH s'exécute sur le port TCP 22. Si le port a été modifié pour des raisons de sécurité renforcée, vous devez spécifier le port correct lors de la connexion, ou vous assurer que le serveur écoute sur le port attendu.

A. Examiner `sshd_config`

Examinez le fichier de configuration SSH, généralement situé à /etc/ssh/sshd_config. Recherchez la directive Port :

# Exemple de /etc/ssh/sshd_config
Port 2222  # Si ce n'est pas 22, vous devez le spécifier côté client

Si vous modifiez ce fichier, vous devez redémarrer le service sshd pour que les modifications prennent effet.

B. Vérifier les sockets d'écoute

Utilisez ss ou netstat pour confirmer que sshd écoute activement sur l'interface et le port attendus. Nous vérifions le port 22 ici :

# Utilisation de ss (préféré sur les systèmes modernes)
sudo ss -tuln | grep 22

# Sortie attendue montrant l'état d'écoute :
# LISTEN 0      128    0.0.0.0:22               0.0.0.0:*

Si rien n'apparaît pour le port 22, le démon n'est pas en cours d'exécution ou est configuré pour écouter sur une adresse/un port différent.

3. Vérifications du pare-feu et du réseau

Un pare-feu bloquant le trafic avant qu'il n'atteigne le processus sshd entraînera souvent un délai d'attente (timeout), mais peut parfois se présenter comme un refus. Il est essentiel de confirmer les règles du pare-feu côté serveur.

Commandes de pare-feu courantes (UFW sur Ubuntu/Debian) :

Assurez-vous que le trafic SSH est autorisé :

# Vérifier l'état actuel
sudo ufw status

# Autoriser le trafic sur le port 22 par défaut
sudo ufw allow ssh
# OU par numéro de port
sudo ufw allow 22/tcp

# Recharger les règles du pare-feu
sudo ufw reload

⚠️ Avertissement sur les pare-feu externes : Si vous vous connectez depuis un réseau distant, assurez-vous que tous les dispositifs réseau intermédiaires, les groupes de sécurité cloud (tels que les groupes de sécurité AWS ou les NSG Azure), ou les pare-feu matériels autorisent explicitement le trafic sur le port SSH.

Partie 2 : Dépannage de la "Permission refusée"

Si vous vous connectez avec succès au serveur mais recevez immédiatement "Permission denied (publickey,password)", le problème est strictement lié à l'authentification.

1. Vérifier le nom d'utilisateur et le mot de passe

C'est la vérification la plus simple, mais souvent négligée :

Nom d'utilisateur : Utilisez-vous le bon nom d'utilisateur pour le système cible ? La connexion en tant que root peut être désactivée.
Mot de passe : Si vous utilisez l'authentification par mot de passe, vérifiez le verrouillage des majuscules, les fautes de frappe et assurez-vous que le compte n'est pas verrouillé.

Vérification côté client : Pour afficher une sortie de débogage détaillée, exécutez votre client avec les drapeaux de verbosité :

ssh -vvv user@hostname

Cette sortie montrera clairement quelles méthodes d'authentification le client a tentées et lesquelles le serveur a rejetées.

2. Échecs d'authentification par clé

L'authentification par clé est supérieure, mais les erreurs de configuration sont des causes fréquentes de refus.

A. Permissions incorrectes sur le répertoire `.ssh`

SSH est extrêmement strict concernant les permissions de fichiers pour des raisons de sécurité. Si les permissions sont trop permissives, le serveur ignorera complètement le fichier de clé.

Sur le serveur distant (Correction des permissions) :

# Les permissions du répertoire personnel de l'utilisateur sont généralement correctes, mais vérifiez le dossier .ssh
chmod 700 ~/.ssh

# Le fichier authorized_keys doit être inscriptible uniquement par le propriétaire
chmod 600 ~/.ssh/authorized_keys

B. Clé absente ou format incorrect

Assurez-vous que votre clé publique (id_rsa.pub ou similaire) est correctement ajoutée au fichier ~/.ssh/authorized_keys du serveur pour l'utilisateur cible. Chaque clé doit être sur sa propre ligne, sans sauts de ligne insérés au milieu de la chaîne de clé.

C. Configuration du serveur désactivant les clés

Vérifiez le fichier /etc/ssh/sshd_config sur le serveur pour vous assurer que l'authentification par clé est autorisée :

PubkeyAuthentication yes

# Assurez-vous que l'authentification par mot de passe n'est pas désactivée si vous comptez sur les mots de passe
PasswordAuthentication yes

3. Investigation des journaux côté serveur

Lorsque l'authentification échoue, les journaux du serveur sont la source ultime de vérité. Recherchez les messages liés à la tentative de connexion échouée.

Emplacements courants des journaux :

Debian/Ubuntu: /var/log/auth.log
RHEL/CentOS/Fedora: /var/log/secure

Utilisez grep pour filtrer les tentatives de connexion récentes :

# Sur les systèmes RHEL/CentOS
sudo grep 'Failed password' /var/log/secure

# Ou recherchez l'activité SSH générale
sudo tail -f /var/log/secure

Les messages de journal indiquent souvent explicitement pourquoi la clé a été rejetée (par exemple, mauvaises options, aucune clé correspondante trouvée ou contexte utilisateur incorrect).

Résumé des bonnes pratiques pour un accès SSH fiable

Utiliser des paires de clés : Désactivez l'authentification par mot de passe (PasswordAuthentication no) dans sshd_config une fois l'accès par clé vérifié.
Changer le port par défaut : Déplacer SSH hors du port 22 réduit le bruit des scans automatisés.
Utiliser PermitRootLogin no : Forcez l'accès administratif via des utilisateurs standard, obligeant l'utilisation de sudo.
Sauvegarder la configuration : Avant d'apporter des modifications importantes à /etc/ssh/sshd_config, sauvegardez toujours le fichier original :
bash sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F)
Tester localement : Après des modifications de configuration, testez la connectivité localement sur le serveur (si possible) avant de déconnecter votre session active pour éviter de vous bloquer.

En vérifiant systématiquement l'état du service, le chemin réseau et les couches de configuration d'authentification, vous pouvez résoudre rapidement les frustrantes erreurs Connection Refused et Permission Denied inhérentes à la gestion des accès à distance.