Dépannage des erreurs SSH courantes : Connexion refusée et refus d'authentification

Les échecs SSH sont plus faciles à résoudre lorsque vous séparez les problèmes de transport des problèmes d'authentification. Connexion refusée signifie que votre client SSH a atteint un hôte, mais que rien n'a accepté la connexion TCP sur ce port. Permission refusée signifie que le serveur SSH a répondu, mais qu'il a rejeté votre connexion. Ce sont des incidents différents, même s'ils donnent tous deux l'impression de « ne pas pouvoir entrer ».

Gardez une session SSH active ouverte pendant que vous modifiez les paramètres du serveur. La plupart des pannes SSH les plus douloureuses surviennent lorsque quelqu'un modifie /etc/ssh/sshd_config, redémarre le service, se déconnecte et découvre seulement alors que la nouvelle configuration bloque toutes les voies de connexion.

Comprendre les erreurs : Refusé vs. Refusé

Lisez le message exact du client avant de modifier quoi que ce soit :

Connexion refusée : l'hôte a activement rejeté la connexion TCP, généralement parce que sshd n'écoute pas sur ce port ou qu'un pare-feu le rejette.
Connexion expirée : les paquets sont supprimés ou le chemin réseau est interrompu. Cela est plus probablement dû à un pare-feu, une route, un VPN, un groupe de sécurité ou une mauvaise adresse IP.
Permission refusée (publickey) : le serveur est accessible, mais il n'a pas accepté votre clé.
Permission refusée (publickey,password) : le serveur a essayé une ou plusieurs méthodes d'authentification et les a rejetées.
Échec de la vérification de la clé d'hôte : votre client ne fait pas confiance à l'identité du serveur actuellement présentée pour ce nom d'hôte ou cette adresse IP.

Partie 1 : Dépannage de la connexion refusée

ssh : connect to host example port 22 : Connection refused pointe généralement vers l'hôte ou le port distant. La machine a répondu, mais SSH n'acceptait pas les connexions à cet endroit.

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 ne fonctionne pas ou a planté.

Étapes concrètes (sur le serveur distant) :

Sur de nombreuses distributions Linux, le service s'appelle sshd ; sur Debian et Ubuntu, il s'appelle souvent ssh. Essayez celui que votre système utilise :

systemctl status sshd
systemctl status ssh

Si le service est inactif ou a échoué, démarrez-le :

sudo systemctl start sshd
sudo systemctl enable sshd

Si sshd ne parvient pas à démarrer après un changement de configuration, validez la configuration :

sudo sshd -t

Cette commande est l'une des vérifications les plus sûres que vous puissiez effectuer avant de redémarrer SSH.

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

Par défaut, SSH utilise le port TCP 22, mais de nombreux serveurs utilisent un port différent. Si le serveur écoute sur 2222, la commande client doit l'inclure :

ssh -p 2222 [email protected]

A. Examiner `sshd_config`

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

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

Après avoir modifié le fichier, exécutez sudo sshd -t avant de recharger. Si la syntaxe est valide, rechargez ou redémarrez le service. Le rechargement est généralement moins perturbateur :

sudo systemctl reload sshd

B. Vérifier les sockets d'écoute

Utilisez ss pour confirmer que sshd écoute :

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 SSH écoute uniquement sur 127.0.0.1:22, les clients distants ne peuvent pas se connecter. S'il écoute sur 0.0.0.0:22 ou une adresse d'interface privée spécifique, l'accès à distance peut être possible en fonction des règles du pare-feu.

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

Un pare-feu qui supprime les paquets provoque généralement un délai d'attente. Un pare-feu qui rejette les paquets peut provoquer un refus. Vérifiez à la fois le pare-feu de l'hôte et tout pare-feu réseau en dehors de l'hôte.

Commandes courantes du pare-feu (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 par défaut 22
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

Les groupes de sécurité cloud, les ACL réseau, les routes VPN et les pare-feu de bureau peuvent bloquer SSH avant que le trafic n'atteigne le serveur. Si sshd écoute et que le pare-feu de l'hôte est ouvert, testez à partir d'une machine située dans le même réseau privé. Cela vous indique si le problème est local au serveur ou quelque part le long du chemin externe.

Partie 2 : Dépannage du refus d'authentification

Si le serveur répond par Permission refusée, le chemin réseau fonctionne. Concentrez-vous sur le nom d'utilisateur, les méthodes d'authentification autorisées, les clés, l'état du compte et les autorisations de fichiers.

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 : Les images cloud utilisent souvent des utilisateurs spécifiques tels que ubuntu, ec2-user, admin, debian ou rocky. root peut être désactivé.
Mot de passe : Si l'authentification par mot de passe est activée, vérifiez les fautes de frappe, le verrouillage du compte, les mots de passe expirés et les règles PAM.
Port et hôte : Un nombre surprenant d'échecs d'authentification sont causés par une connexion au mauvais serveur qui exécute SSH.

Vérification côté client : Pour afficher une sortie de débogage détaillée, exécutez votre client avec des indicateurs verbeux :

ssh -vvv user@hostname

Cette sortie montrera clairement les méthodes d'authentification que le client a tentées et celles que le serveur a rejetées.

2. Échecs d'authentification par clé

L'authentification par clé échoue lorsque le client propose la mauvaise clé privée, que le serveur ne possède pas la clé publique correspondante, que les autorisations sont trop ouvertes ou que sshd_config bloque la connexion.

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

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

Sur le serveur distant (correction des autorisations) :

# Les autorisations 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 ne doit être accessible en écriture que par le propriétaire
chmod 600 ~/.ssh/authorized_keys

Vérifiez également la propriété :

chown -R "$USER:$USER" ~/.ssh

Sur le serveur, StrictModes est généralement activé. Si le répertoire personnel, le répertoire .ssh ou le fichier authorized_keys est accessible en écriture par d'autres utilisateurs, sshd peut ignorer la clé.

B. Clé absente ou mal formatée

Assurez-vous que la clé publique se trouve dans le fichier ~/.ssh/authorized_keys de l'utilisateur cible, une clé par ligne. La clé privée reste sur votre client. Ne collez pas la clé privée dans authorized_keys.

Depuis le client, forcez une clé spécifique lors du débogage :

ssh -i ~/.ssh/id_ed25519 -vvv [email protected]

Dans la sortie verbeuse, recherchez les lignes indiquant quelles clés ont été proposées et pourquoi le serveur les a acceptées ou rejetées.

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

Vérifiez /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

Si AllowUsers, AllowGroups, DenyUsers ou DenyGroups sont présents, ils peuvent remplacer ce qui ressemble à une configuration de clé valide. Un utilisateur avec la bonne clé peut toujours être bloqué par ces directives.

3. Investigation des journaux côté serveur

Les journaux du serveur vous indiquent généralement la véritable raison d'un refus. Gardez un terminal ouvert sur le serveur et surveillez les journaux tout en tentant une connexion depuis le client.

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

Sur les systèmes avec journalisation systemd, c'est souvent plus facile :

sudo journalctl -u sshd -f
sudo journalctl -u ssh -f

Les messages du journal peuvent indiquer « bad ownership or modes », « user not allowed », « invalid user », « authentication refused » ou des échecs de compte PAM. Ces messages sont plus fiables que de deviner du côté client.

Échecs de vérification de la clé d'hôte

Host key verification failed n'est pas la même chose qu'un mauvais mot de passe ou une mauvaise clé. Cela signifie que votre client a enregistré une identité de serveur pour ce nom d'hôte ou cette adresse IP, et que le serveur présente maintenant une identité différente. Cela peut se produire après une reconstruction, une réutilisation d'adresse IP, un changement d'équilibreur de charge ou un véritable risque d'interception.

Ne supprimez pas aveuglément l'avertissement dans un environnement de production. Vérifiez l'empreinte du serveur via votre console cloud, votre gestion de configuration ou un canal de confiance existant. Une fois que vous savez que le changement est attendu, supprimez l'ancienne entrée :

ssh-keygen -R example.com
ssh-keygen -R 192.0.2.10

Connectez-vous ensuite et acceptez la nouvelle clé d'hôte uniquement si l'empreinte correspond à ce que vous attendez.

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

Utilisez des paires de clés : Désactivez l'authentification par mot de passe uniquement après avoir testé l'accès par clé dans une deuxième session.
Limitez qui peut se connecter : Utilisez AllowUsers ou AllowGroups le cas échéant, mais documentez-le afin que les futurs opérateurs ne recherchent pas de faux problèmes d'autorisation.
Utilisez PermitRootLogin no : Préférez les utilisateurs normaux avec sudo.
Sauvegardez la configuration : Avant de modifier /etc/ssh/sshd_config, copiez-le :

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F) ``` 5. Validez avant de recharger : Exécutez sudo sshd -t. 6. Gardez un chemin de secours : Pour les serveurs cloud, sachez comment utiliser la console série, le mode de secours, la fonction de connexion d'instance ou la gestion de configuration si SSH se casse.

Le chemin le plus court pour le dépannage SSH est : identifier l'erreur exacte, prouver si le serveur écoute, prouver si le chemin réseau atteint ce port, puis lire les journaux du serveur pour les échecs d'authentification. Deviner prend généralement plus de temps que d'effectuer ces vérifications dans l'ordre.