Le message SSH indique la couche en cause. « Connection refused » : le serveur répond mais sshd n’écoute pas sur ce port. « Connection timed out » : un pare-feu ou le réseau bloque. « Permission denied (publickey) » : la connexion aboutit mais la clé est refusée. Lancez ssh -v, puis reprenez la main par la console de secours de l’hébergeur.
Trois messages, trois diagnostics différents. Avec un refus de connexion, la machine est joignable mais personne n’écoute sur le port : service arrêté, mauvais port, configuration invalide. Avec un délai dépassé, les paquets n’arrivent jamais : pare-feu, adresse IP bannie, serveur éteint ou réseau coupé. Avec un refus de clé, tout fonctionne sauf l’authentification : clé absente, droits trop larges sur ~/.ssh, utilisateur incorrect.
Ne cherchez pas à contourner le problème depuis l’extérieur : le moyen le plus sûr de reprendre la main est la console de secours (KVM ou VNC) de l’hébergeur, qui donne un accès local sans SSH. Pour le reste, la sortie de ssh -v désigne le coupable.
Lire le message exact avec ssh -v
Relancez la connexion avec ssh -v utilisateur@adresse-ip (-vv ou -vvv pour plus de détails). Les premières lignes montrent si la connexion TCP s’établit, la version du serveur, puis les clés proposées et la méthode refusée. Notez le dernier message : Connection refused, Connection timed out, Permission denied (publickey) ou Host key verification failed. Les sections suivantes correspondent à chacun. Vérifiez aussi que vous visez le bon port : ssh -p 2222 utilisateur@adresse-ip si le service n’écoute pas sur le port 22.
Ouvrir la console de secours de l’hébergeur
Dans l’espace client, ouvrez la console KVM, VNC ou « console web » de votre serveur et connectez-vous avec le compte d’origine, en root ou avec un utilisateur autorisé à utiliser sudo. Si vous n’avez pas de mot de passe local, la plupart des hébergeurs permettent d’en réinitialiser un, ou de démarrer en mode rescue. Cette console reste utilisable même quand SSH, le pare-feu ou le réseau sont mal réglés, ce qui en fait le point de départ de toutes les corrections suivantes.
Contrôler le service sshd et son port
Dans la console, lancez systemctl status ssh (Debian, Ubuntu) ou systemctl status sshd (autres distributions). Démarrez-le au besoin avec systemctl start ssh. Si le démarrage échoue, sshd -t teste la configuration et indique la ligne fautive dans /etc/ssh/sshd_config. Confirmez le port avec ss -tlnp | grep sshd et comparez-le à la directive Port. Sous Ubuntu récent, l’activation par socket peut aussi imposer de relire ssh.socket. Après correction, systemctl restart ssh, puis testez dans une seconde session avant de fermer la console.
Examiner le pare-feu : ufw et nftables
Un Connection timed out pointe presque toujours vers un filtrage. Listez les règles avec ufw status verbose ou, sans ufw, nft list ruleset. Autorisez le port SSH par ufw allow 22/tcp (ou votre port personnalisé) en veillant à ne jamais activer le pare-feu avant d’avoir autorisé ce port. Vérifiez aussi le pare-feu externe de l’hébergeur, souvent un groupe de sécurité configuré dans l’espace client, qui peut bloquer le port avant même d’atteindre le serveur. Ne désactivez pas le pare-feu pour contourner : ajoutez la règle précise.
Vérifier si fail2ban a banni votre adresse
Après plusieurs échecs de connexion, fail2ban bloque l’adresse IP pour une durée donnée : tout paraît alors en délai dépassé, uniquement depuis votre poste. Dans la console, fail2ban-client status sshd liste les adresses bannies. Débloquez la vôtre avec fail2ban-client set sshd unbanip votre.adresse.ip. Pour connaître votre adresse publique, demandez-la depuis votre poste avec curl ifconfig.me. Si le bannissement vient d’une attaque réelle, lisez la page sur les attaques par force brute en SSH.
Corriger les permissions de ~/.ssh et authorized_keys
Permission denied (publickey) signifie que la clé proposée n’est pas acceptée. Sur le serveur, contrôlez avec ls -ld ~ ~/.ssh ~/.ssh/authorized_keys : le dossier personnel ne doit pas être modifiable par les autres, ~/.ssh doit être en 700 et authorized_keys en 600, le tout appartenant à l’utilisateur concerné. Appliquez chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys et chown -R utilisateur:utilisateur ~/.ssh. Le journal, journalctl -u ssh -n 30, précise souvent la raison, par exemple Authentication refused: bad ownership or modes.
Réajouter la bonne clé publique
Sur votre poste, affichez la clé publique avec cat ~/.ssh/id_ed25519.pub (ou le fichier de votre clé) et vérifiez qu’elle figure bien, sur une seule ligne, dans ~/.ssh/authorized_keys du compte visé. Ajoutez-la depuis la console si elle manque. Vérifiez que /etc/ssh/sshd_config n’interdit pas le compte (AllowUsers, PermitRootLogin) et que PubkeyAuthentication yes est actif. Rechargez avec systemctl reload ssh. En cas d’avertissement REMOTE HOST IDENTIFICATION HAS CHANGED, ne l’ignorez pas : après une réinstallation légitime, supprimez l’ancienne empreinte avec ssh-keygen -R adresse-ip.
Sécuriser l’accès une fois rétabli
Gardez une seconde session ouverte pendant tout changement de sshd_config. Conservez au moins deux moyens de reprise : une clé de secours stockée hors du poste habituel et l’accès à la console de l’hébergeur. Désactivez l’authentification par mot de passe seulement quand la connexion par clé fonctionne, et surveillez les connexions inhabituelles avec last et journalctl -u ssh. Si une connexion inconnue apparaît, consultez le guide sur un serveur piraté.
Questions fréquentes
Que signifie « ssh: connect to host … port 22: Connection refused » ?
La machine répond, mais aucun service n’écoute sur ce port : sshd est arrêté, configuré sur un autre port ou en erreur. Depuis la console de l’hébergeur, lancez systemctl status ssh, sshd -t et ss -tlnp pour savoir lequel.
Quelle différence entre « Connection refused » et « Connection timed out » ?
Un refus est une réponse immédiate : la machine est joignable mais le port est fermé. Un délai dépassé est une absence de réponse : un pare-feu supprime les paquets, l’adresse est bannie ou le serveur est injoignable. Les corrections diffèrent complètement.
Pourquoi « Permission denied (publickey) » alors que ma clé est bonne ?
Les causes fréquentes sont des droits trop larges sur ~/.ssh ou authorized_keys, un mauvais utilisateur, une clé collée sur plusieurs lignes ou un agent qui propose une autre clé. Lancez ssh -v -i chemin/de/la/cle utilisateur@adresse-ip et lisez les clés réellement essayées.
Comment reprendre l’accès à un serveur dont SSH est cassé ?
Utilisez la console de secours KVM ou VNC de l’hébergeur, ou son mode rescue. Vous obtenez un accès local pour relancer sshd, ouvrir le port dans le pare-feu, débannir votre adresse ou corriger les clés, sans passer par le réseau.
Fail2ban m’a bloqué, comment me débannir ?
Depuis la console ou une autre adresse, lancez fail2ban-client status sshd pour voir les adresses bannies, puis fail2ban-client set sshd unbanip votre.adresse.ip. Ajoutez ensuite votre adresse fixe à ignoreip dans la configuration pour éviter la récidive.
Sources
- ssh_config(5) — man7.org
- sshd_config(5) — man7.org
- OpenSSH server — documentation Ubuntu Server
- Fail2ban — wiki Debian