Connexion SSH refusée : les causes les plus fréquentes et leurs solutions

SSH est l’un des outils les plus utilisés pour administrer un serveur Linux à distance. Il permet d’exécuter des commandes, de transférer des fichiers et de gérer des machines sans accès physique.

Cependant, une connexion SSH peut échouer pour plusieurs raisons : service arrêté, port incorrect, pare-feu, clé rejetée ou problème réseau.

Le message affiché par le terminal fournit souvent un premier indice. Dans ce guide, nous allons examiner les erreurs les plus courantes et les méthodes permettant de les diagnostiquer sans modifier inutilement la configuration du serveur.

1. Identifier le message d’erreur exact

Commencez par lancer une connexion SSH en mode détaillé :

ssh -v utilisateur@adresse_du_serveur

Remplacez utilisateur et adresse_du_serveur par vos informations réelles.

L’option -v affiche des informations supplémentaires sur la tentative de connexion. Pour obtenir davantage de détails, vous pouvez utiliser -vv ou -vvv.

Trois erreurs reviennent fréquemment :

Connection refused : la connexion a été refusée par l’hôte distant ou un équipement réseau.
Connection timed out : la connexion n’a pas abouti dans le délai imparti.
Permission denied (publickey) : le serveur n’a pas accepté la méthode d’authentification par clé proposée.

Ces messages correspondent à des situations différentes. Il est donc important de commencer par le diagnostic plutôt que de modifier immédiatement les clés ou le pare-feu.

2. Erreur Connection refused : vérifier le service SSH

Le message Connection refused indique généralement que la connexion TCP a été refusée. Le service SSH peut être arrêté, écouter sur un autre port ou ne pas être accessible à l’adresse utilisée.

Si vous avez accès à la console du serveur, vérifiez l’état du service :

sudo systemctl status ssh

Sur certaines distributions, notamment celles utilisant une unité nommée sshd, utilisez plutôt :

sudo systemctl status sshd

Si le service est arrêté, examinez d’abord les journaux :

sudo journalctl -u ssh -n 100 --no-pager

Adaptez le nom de l’unité à votre distribution.

Vérifiez ensuite les ports en écoute :

sudo ss -lntp

Recherchez le port utilisé par SSH, généralement le port 22 par défaut.

Si le service est actif mais que le port attendu n’apparaît pas, examinez sa configuration et ses journaux avant de tenter un redémarrage.

3. Erreur Connection timed out : examiner le réseau

Un délai d’attente indique que la connexion n’a pas abouti. Le problème peut venir du pare-feu, du routage, de l’adresse IP, d’une règle réseau de l’hébergeur ou d’un filtrage intermédiaire.

Vérifiez d’abord que vous utilisez la bonne adresse et le bon port.

Pour tester un port TCP depuis votre ordinateur, si nc est installé :

nc -vz adresse_du_serveur 22

Remplacez 22 par le port SSH réel.

Si la connexion échoue, vérifiez les éléments suivants :

Le serveur est-il démarré et possède-t-il la bonne adresse IP ?
Le service SSH écoute-t-il sur le port attendu ?
Le pare-feu du système autorise-t-il la connexion ?
L’hébergeur applique-t-il des règles réseau externes ?
Le réseau depuis lequel vous vous connectez bloque-t-il ce port ?

Une requête ICMP ou un ping qui échoue ne prouve pas à lui seul que le serveur est hors ligne : certains réseaux bloquent ces requêtes.

4. Vérifier le port SSH utilisé

SSH utilise généralement le port 22, mais une configuration peut en employer un autre.

Pour vous connecter sur un port différent :

ssh -p 2222 utilisateur@adresse_du_serveur

Ici, 2222 est uniquement un exemple. Utilisez le port configuré sur votre serveur.

Si vous avez accès à la machine, examinez la configuration effective du démon SSH :

sudo sshd -T | grep -i '^port '

Cette commande peut afficher les ports configurés, mais le résultat dépend notamment des fichiers inclus et des paramètres appliqués au service.

Ne changez pas le port du serveur sans préparer la règle de pare-feu correspondante et vérifier que vous disposez d’un moyen alternatif d’accès.

5. Erreur Permission denied (publickey)

Cette erreur apparaît lorsque l’authentification par clé publique échoue. Plusieurs causes sont possibles :

La mauvaise clé privée est utilisée.
La clé publique n’est pas présente dans le compte distant.
Le nom d’utilisateur est incorrect.
Les permissions des fichiers SSH ne sont pas adaptées.
Le serveur n’autorise pas la méthode d’authentification attendue.

Pour sélectionner explicitement une clé privée :

ssh -i ~/.ssh/id_ed25519 utilisateur@adresse_du_serveur

Vérifiez ensuite les fichiers locaux :

ls -l ~/.ssh/

La clé privée ne doit pas être partagée publiquement. En général, elle doit être accessible uniquement à son propriétaire.

Sur le serveur, examinez le fichier authorized_keys du compte concerné :

ls -ld ~/.ssh
ls -l ~/.ssh/authorized_keys

Les permissions requises peuvent varier selon la configuration SSH. Des droits trop permissifs peuvent conduire le serveur à refuser certains fichiers.

Ne remplacez pas les clés et ne supprimez pas les fichiers existants sans avoir vérifié qu’une autre méthode d’accès fonctionne.

6. Vérifier le nom d’utilisateur

Une clé valide ne suffit pas si vous tentez de vous connecter avec le mauvais compte.

Par exemple :

ssh ubuntu@adresse_du_serveur

ou :

ssh debian@adresse_du_serveur

Les noms ci-dessus sont des exemples courants, pas des règles universelles. Le compte initial dépend de l’image système et de la configuration de l’hébergeur.

Consultez les informations fournies lors de la création du serveur ou vérifiez les comptes existants depuis sa console d’administration.

7. Examiner le pare-feu

Sur Ubuntu, UFW peut être utilisé pour gérer les règles du pare-feu.

Affichez les règles :

sudo ufw status verbose

Si le service SSH utilise le profil standard, celui-ci peut être autorisé avec :

sudo ufw allow OpenSSH

Si SSH utilise un port personnalisé, adaptez la règle au port et au protocole réels.

Attention : avant de modifier les règles à distance, vérifiez que le port utilisé pour votre session actuelle reste autorisé. Une règle incorrecte peut vous empêcher de vous reconnecter.

N’oubliez pas non plus le pare-feu externe du fournisseur VPS, qui peut bloquer les connexions même lorsque le pare-feu Linux est correctement configuré.

8. Utiliser les journaux pour trouver la cause

Sur le serveur, les journaux SSH peuvent indiquer si une tentative est arrivée jusqu’au service et pourquoi elle a échoué.

Sur un système utilisant systemd :

sudo journalctl -u ssh --since "30 minutes ago"

Sur certaines distributions, les événements d’authentification sont également disponibles dans des fichiers comme /var/log/auth.log ou /var/log/secure.

Le chemin dépend de la distribution et de sa configuration.

Cherchez des messages concernant l’utilisateur, la clé proposée, les permissions ou les tentatives refusées. Si aucun événement ne correspond à votre tentative, le problème peut se situer avant le service SSH, par exemple au niveau du réseau ou du pare-feu.

9. Éviter de se verrouiller hors du serveur

Lorsqu’on modifie SSH à distance, il est important de préserver une possibilité de récupération.

Avant de désactiver l’authentification par mot de passe ou de modifier le port :

Vérifiez la configuration existante.
Conservez une session SSH déjà ouverte.
Testez la nouvelle configuration avec sudo sshd -t.
Vérifiez les règles du pare-feu.
Ouvrez une nouvelle session pour confirmer que l’accès fonctionne.
Gardez la console de l’hébergeur disponible si elle existe.

Ne fermez pas votre dernière session fonctionnelle avant d’avoir confirmé que les nouvelles connexions sont possibles.

Tableau récapitulatif

Message ou symptôme	Première vérification
`Connection refused`	Service SSH et port en écoute
`Connection timed out`	Réseau, routage et pare-feu
`Permission denied (publickey)`	Clé, utilisateur et permissions
Mauvais port	Option `-p` et configuration du serveur
Aucune trace dans les journaux	Réseau et filtrage avant SSH

FAQ

Pourquoi SSH fonctionnait-il hier et plus aujourd’hui ?

Une mise à jour, un redémarrage, un changement d’adresse IP, une modification du pare-feu ou une modification de configuration peut expliquer le problème. Comparez l’état actuel aux changements récents.

Faut-il changer le port 22 pour sécuriser SSH ?

Changer le port peut réduire certains scans automatisés, mais ce n’est pas une protection suffisante. L’authentification robuste, les mises à jour et les règles d’accès restent essentielles.

Peut-on corriger SSH uniquement depuis son ordinateur ?

Certaines vérifications sont possibles depuis le client, mais les problèmes liés au service, aux permissions ou à la configuration du serveur nécessitent souvent un accès à la console de l’hébergeur ou une autre session administrative.

Que faire si toutes les connexions sont impossibles ?

Utilisez la console de secours ou l’accès série proposé par l’hébergeur, si disponible. Vérifiez le réseau, le service SSH, la configuration et les règles du pare-feu avant de modifier les paramètres.

Conclusion

Pour résoudre une erreur SSH, identifiez d’abord le message exact. Une connexion refusée, un délai d’attente dépassé et une clé rejetée ne se corrigent pas de la même manière.

En procédant par étapes — service, port, réseau, authentification et journaux — vous pouvez souvent retrouver l’accès sans modifier inutilement la configuration de votre serveur.