Différence entre SSH Connection refused et timed out

Signification de "Connection refused" et "Connection timed out" en SSH

Une erreur "Connection refused" et une erreur "Connection timed out" en SSH sont des échecs opposés ; la solution pour l'un ne résout jamais l'autre. "Refused" signifie que votre paquet a atteint le serveur et que le noyau du serveur a répondu qu'aucun service n'écoute sur ce port. "Timed out" signifie que votre paquet n'a atteint personne capable de répondre ; votre client a donc attendu avant d'abandonner. "Refused" est un problème de service sur le serveur. "Timed out" est un problème de chemin réseau en amont.

Lisez la ligne exacte affichée par votre client, car le libellé constitue le diagnostic complet.

ssh: connect to host 203.0.113.10 port 22: Connection refused
ssh: connect to host 203.0.113.10 port 22: Connection timed out

Le délai est le second indice. "Refused" survient instantanément, environ le temps d'un aller-retour réseau. "Timed out" reste en attente pendant plusieurs secondes avant de s'afficher, car le client continue de retransmettre ses paquets avant de renoncer. macOS affiche Operation timed out pour la même condition. Si le protocole lui-même est nouveau pour vous, le fonctionnement de SSH et le rôle de sshd constitue le socle théorique sur lequel ce guide s'appuie.

Pourquoi « Connection refused » est une bonne nouvelle

Refused correspond à un paquet TCP (transmission control protocol) de réinitialisation (reset). Votre client envoie un paquet SYN vers le port 22. Il traverse Internet, arrive sur la pile réseau du serveur, et le noyau ne trouve aucun socket en écoute sur ce port ; il répond donc par un paquet RST (reset). Votre client SSH traduit ce RST par le message Connection refused.

Ce paquet de retour prouve beaucoup de choses. L'adresse est correcte. L'hôte est sous tension et routé. Aucun équipement sur le chemin ne rejette silencieusement le trafic vers ce port, car une réponse provient de l'extrémité distante. Tous les suspects restants se trouvent donc sur le serveur lui-même.

• sshd n'est pas en cours d'exécution, car il a échoué au démarrage ou n'a jamais été activé.
• sshd est en écoute sur un autre port, généralement après une modification de durcissement (hardening).
• sshd est lié à une seule adresse, telle que ListenAddress 127.0.0.1, de sorte que seul le serveur lui-même peut l'atteindre.
• Un pare-feu est configuré pour rejeter (reject) plutôt que pour abandonner (drop) les paquets, le pare-feu envoie donc le RST pour le compte de l'hôte. L'action reject de ufw et une règle nftables se terminant par reject with tcp reset produisent toutes deux ce résultat.

Un cas supplémentaire ressemble à ceux-ci sans en être un : vous avez saisi une adresse qui appartient à un autre hôte actif. Cet hôte répond à votre SYN, n'a pas de service SSH sur le port 22, et vous refuse poliment la connexion. Vérifiez l'adresse avant de passer une heure sur le mauvais serveur. Comprendre ce qu'est réellement un port en écoute sous Linux permet de lire la suite de cette section plus rapidement.

Comment corriger une erreur Connection refused

Vous ne pouvez pas corriger ce problème via SSH, car c'est précisément SSH qui est défaillant. Ouvrez la console web ou la console série de votre fournisseur, connectez-vous, puis exécutez les commandes suivantes.

systemctl status ssh
sudo ss -tlnp
sudo sshd -T | grep -Ei '^(port|listenaddress|addressfamily)'

systemctl status ssh utilise le nom de l'unité sur Ubuntu et Debian. Sur RHEL et ses dérivés comme AlmaLinux, l'unité est sshd. ss -tlnp liste tous les sockets TCP en état d'écoute ainsi que le processus associé ; c'est la source de vérité : si aucune ligne ne mentionne sshd, alors rien n'écoute, peu importe ce que prétend le fichier de configuration. sshd -T affiche la configuration effective après la fusion de chaque fichier Include, ce qui permet de repérer un port oublié dans /etc/ssh/sshd_config.d/.

Lisez attentivement la colonne d'adresse. 0.0.0.0:22 signifie toutes les adresses IPv4 de la machine. [::]:22 signifie toutes les adresses IPv6. 127.0.0.1:22 signifie uniquement le loopback ; par conséquent, toute connexion distante vers cette adresse est refusée, alors qu'un ssh localhost local fonctionne parfaitement.

Si rien n'est en écoute, démarrez le service et lisez l'erreur affichée s'il refuse de se lancer.

sudo sshd -t
sudo systemctl enable --now ssh
sudo journalctl -u ssh -n 50 --no-pager

sshd -t analyse la configuration et affiche le fichier ainsi que le numéro de ligne de toute directive erronée sans affecter le service en cours d'exécution. Exécutez-le avant chaque redémarrage, car une configuration rejetée entraîne l'arrêt de sshd au démarrage, ce qui provoquera le refus de votre prochaine connexion.

Le piège de l'activation par socket sur Ubuntu

Ubuntu 24.04 fournit une unité de socket systemd pour OpenSSH. Lorsque cette unité est activée, systemd conserve le port d'écoute et démarre sshd à chaque connexion. Par conséquent, Port 2222 dans sshd_config ne change rien et la machine continue de répondre sur l'ancien port. Vérifiez le mode utilisé avant toute modification.

systemctl is-enabled ssh.socket
systemctl status ssh.socket

Si le socket est activé, définissez le port dans l'unité de socket au lieu de sshd_config.

sudo systemctl edit ssh.socket

[Socket]
ListenStream=
ListenStream=2222

La ligne ListenStream= vide est nécessaire, car les paramètres de liste de systemd s'ajoutent à la configuration existante. Si vous l'omettez, le serveur écoutera sur les deux ports. Appliquez la modification avec sudo systemctl daemon-reload et sudo systemctl restart ssh.socket, puis vérifiez avec sudo ss -tlnp que le nouveau port est bien celui qui est utilisé. Le changement de port est une étape courante du durcissement SSH sur un VPS, et c'est l'étape qui verrouille le plus souvent l'accès aux utilisateurs.

Pourquoi « Connection timed out » signifie qu'aucune réponse n'a été reçue

Un timeout est un silence. Votre client a envoyé un SYN, l'a retransmis plusieurs fois pendant une minute ou deux, et n'a jamais reçu un seul paquet en retour. Rien n'est prouvé concernant le serveur, car rien n'a été entendu de sa part.

Le silence est exactement ce qu'une règle DROP produit, et le rejet silencieux (dropping) est intentionnel. Un rejet explicite indique à quiconque scanne le réseau que l'hôte existe ; c'est pourquoi ufw et tous les pare-feux réseau des fournisseurs cloud écartent les paquets indésirables sans rien renvoyer. Votre timeout est généralement le résultat d'un pare-feu qui fait son travail sur un port que vous souhaitiez ouvrir.

• L'adresse est incorrecte : un enregistrement DNS pointe toujours vers un serveur que vous avez réinstallé, ou une erreur de frappe mène à une adresse inutilisée.
• L'hôte n'est pas actif : il est éteint ou en cours de redémarrage. Une suspension de service par le fournisseur pour des raisons de facturation produit le même résultat vu de l'extérieur.
• Le pare-feu de l'hôte bloque le port 22, le plus souvent parce que ufw enable a été exécuté avant qu'une règle d'autorisation ne soit définie.
• Un pare-feu du fournisseur situé devant l'instance bloque le trafic, et le système d'exploitation ne voit jamais le paquet.
• Votre propre réseau bloque le port 22 en sortie, ce qui est courant sur les connexions d'entreprise ou d'hôtel.

Run the test from the right side of the connection

Here is the mistake that costs the most time. You cannot diagnose a dropped packet from inside the box the packets are not reaching. If you could log in to run the command, you would not have the problem. Every command in this section runs on your own machine.

getent hosts vps.example.com
ssh -G vps.example.com | grep -Ei '^(hostname|port|user)'
ssh -vvv -o ConnectTimeout=10 user@vps.example.com
nc -vz -w 5 203.0.113.10 22

getent hosts shows the address your machine will really use, which catches a stale DNS record in seconds. ssh -G prints the settings your client applies after reading ~/.ssh/config, so it catches an old Host block that quietly rewrites the hostname, the port or the user. ssh -vvv shows how far the attempt got: a last line about connecting to the address followed by a long pause is a timeout, while a line reporting the remote OpenSSH version means TCP already succeeded and your real problem is authentication. On Windows, Test-NetConnection 203.0.113.10 -Port 22 in PowerShell replaces nc.

Test the port, not the host. A failed ping proves nothing, because many providers filter ICMP (internet control message protocol) at the edge. A successful ping proves nothing either, because it says nothing about port 22.

Then change the one variable no command can change for you: your network. Retry from a phone hotspot. If the hotspot connects and your desk does not, the block is on your side of the internet, or your office address has been banned on the server.

Le pare-feu du fournisseur invisible depuis le serveur

La plupart des panneaux de contrôle VPS proposent un pare-feu réseau, parfois appelé groupe de sécurité ou pare-feu cloud, qui s'exécute en amont de votre instance et gère sa propre liste de règles. ufw status sur le serveur ne peut pas le voir, ce qui explique pourquoi la phrase « mais j'ai déjà autorisé le port 22 » est si fréquente. Ouvrez le panneau et consultez cette liste avant de modifier la moindre règle sur la machine.

Une commande permet de trancher la question, mais elle nécessite un accès à la console. Lancez-la sur le serveur, puis essayez de vous connecter depuis votre ordinateur portable pendant qu'elle tourne.

sudo tcpdump -ni any tcp port 22

Si rien n'apparaît pendant que votre client tente de se connecter, les paquets sont rejetés avant d'atteindre le système d'exploitation. La cause est donc le pare-feu du fournisseur ou la route vers l'hôte. Si les paquets SYN arrivent mais qu'aucune réponse ne repart, le rejet est local et provient de ufw ou nftables. Ce test unique permet de diviser en deux les causes possibles d'un timeout, ce qui justifie l'utilisation de la console.

Ordre des règles ufw, IPv6 et auto-bannissement

L'erreur d'ordre dans ufw est la cause la plus fréquente de verrouillage. sudo ufw enable applique une politique par défaut de refus des connexions entrantes immédiatement. Si aucune règle SSH n'est définie, votre session actuelle survit grâce à l'état établi, mais toute nouvelle connexion expire. Autorisez d'abord, puis activez.

sudo ufw allow OpenSSH
sudo ufw status verbose

Le profil d'application OpenSSH ne couvre que le port 22. Si vous prévoyez de déplacer SSH sur le port 2222, la règle nécessaire est sudo ufw allow 2222/tcp, à ajouter avant de modifier le port et non après. L'ensemble des règles est détaillé dans les bases du pare-feu ufw pour un VPS, et l'ordre sécurisé est abordé dans que faire durant les dix premières minutes sur un nouveau VPS.

L'IPv6 provoque un délai d'attente qui semble inexplicable. Si le nom d'hôte possède un enregistrement AAAA, votre client tente d'abord l'IPv6. Un serveur dont les règles IPv6 sont absentes bloque la connexion, alors qu'une tentative en IPv4 fonctionne. Gérez les deux protocoles séparément.

ssh -4 user@vps.example.com
ssh -6 user@vps.example.com

Si -4 se connecte et que -6 échoue, le correctif concerne les règles IPv6 du serveur. Ouvrir le même port pour l'IPv6 dans ufw détaille la procédure.

Il est également possible que vous vous soyez banni vous-même. fail2ban surveille le journal d'authentification et insère une règle de pare-feu contre les adresses qui échouent de manière répétée. Une mauvaise clé ou un script qui tente de se connecter en arrière-plan peut verrouiller l'adresse IP de tout un bureau. Un bannissement qui ignore les paquets ressemble à un délai d'attente. Un bannissement qui rejette renvoie No route to host. Depuis la console :

sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 198.51.100.24

Ajouter votre propre adresse dans ignoreip fait partie de une configuration fonctionnelle de fail2ban sur Ubuntu 24.04.

Erreurs qui ne sont ni des refus ni des délais d'attente

No route to host signifie qu'un message ICMP unreachable a été reçu. Soit votre machine n'a aucune route vers ce réseau, soit un équipement sur le chemin a répondu par un rejet administratif, ce qui correspond au comportement d'une règle REJECT dans iptables.

Network is unreachable provient de votre propre machine. Elle ne possède aucune route pour cette famille d'adresses ; c'est la réponse habituelle lorsqu'un nom d'hôte ne résout qu'en une adresse IPv6 sur une connexion limitée à l'IPv4.

kex_exchange_identification: Connection closed by remote host signifie que la connexion TCP a réussi, mais que le serveur a coupé la communication avant la fin de l'échange de clés. Le port est ouvert et sshd est actif ; vérifiez donc la charge du serveur, les MaxStartups, ou un bannissement survenu pendant votre tentative de connexion.

Permission denied (publickey) signifie que vous avez atteint l'étape d'authentification et que celle-ci a échoué. Le réseau et le pare-feu fonctionnent correctement, ce guide ne s'applique donc pas à votre situation. Consultez plutôt corriger Permission denied (publickey) en SSH.

Comment reprendre la main et éviter un nouveau blocage

Chaque hébergeur VPS sérieux fournit une console indépendante du réseau de l'invité : une console série ou un écran VNC accessible via navigateur. Cette console est la voie de secours pour les deux cas de figure de ce guide, car elle reste fonctionnelle même si sshd est arrêté ou si une règle de pare-feu rejette tout le trafic. Trouvez-la dans le panneau d'administration, connectez-vous en tant que root ou avec votre utilisateur habituel, puis effectuez les vérifications ci-dessus. Si vous n'avez jamais défini de mot de passe root, la plupart des panneaux permettent d'en réinitialiser un.

En l'absence de console, le recours est le mode rescue du fournisseur. Il démarre un système de récupération minimal et monte votre disque, vous permettant ainsi de modifier /etc/ssh/sshd_config ou de supprimer une règle de pare-feu hors ligne avant de redémarrer.

Deux habitudes permettent d'éviter le prochain blocage. Gardez une seconde session SSH ouverte à chaque fois que vous modifiez sshd ou le pare-feu, car cette session survit grâce à l'état établi pendant que vous testez la nouvelle configuration. Prévoyez également une annulation automatique avant toute modification risquée du pare-feu.

sudo systemd-run --unit=ufw-rollback --on-active=10min /usr/sbin/ufw disable
sudo systemctl stop ufw-rollback.timer

La première ligne programme ufw pour qu'il se désactive automatiquement dans dix minutes. Appliquez vos nouvelles règles, ouvrez une nouvelle session SSH pour vérifier leur bon fonctionnement, puis exécutez la seconde ligne pour annuler le retour en arrière. Si vous vous bloquez l'accès, attendez dix minutes et le pare-feu se désactivera de lui-même. Le serveur restera sans filtrage jusqu'à ce que vous réactiviez ufw ; utilisez donc cette méthode uniquement lorsque vous êtes devant votre clavier et non comme une solution permanente.

L'ordre des opérations

1. Lisez le texte de l'erreur et notez le temps écoulé avant son apparition.
2. Refused : accédez à la console et vérifiez sudo ss -tlnp pour identifier le socket en écoute, son port et l'adresse sur laquelle il est lié.
3. Timed out : confirmez l'adresse depuis votre propre machine, puis vérifiez le pare-feu du fournisseur dans le panneau de contrôle, et enfin le pare-feu local sur le serveur.
4. Aucune de ces chaînes : vous disposez déjà d'une connexion TCP ; traitez donc le problème comme une question d'authentification ou de charge serveur, et non comme un problème réseau.

FAQ

Pourquoi SSH indique-t-il « Connection refused » alors que sshd est actif ?

Parce qu'un refus provient du socket, pas du service, et qu'un sshd en cours d'exécution peut tout de même vous rejeter. Ouvrez la console de votre fournisseur et exécutez sudo ss -tlnp. Un socket sur 127.0.0.1:22 refuse tout client distant car il est lié uniquement au loopback. Un socket sur un autre port refuse toute connexion tentée sur le port 22. Si l'activation par socket systemd est utilisée, le port provient de ssh.socket et non de sshd_config, vérifiez donc également systemctl is-enabled ssh.socket. Une règle ufw reject renvoie aussi un refus au nom de l'hôte ; consultez donc sudo ufw status verbose avant de tirer une conclusion.

Pourquoi SSH expire-t-il (timeout) alors que ufw autorise le port 22 ?

Parce qu'un timeout signifie qu'aucune réponse n'est parvenue, et ufw n'est pas le seul pare-feu sur le chemin. La plupart des panneaux de contrôle VPS exécutent un pare-feu réseau devant l'instance, et le système d'exploitation ne voit jamais ce que ce pare-feu rejette. Depuis la console, exécutez sudo tcpdump -ni any tcp port 22 et tentez de vous connecter depuis votre ordinateur pendant qu'il tourne. Si aucun paquet n'arrive, le rejet est en amont, dans le panneau de contrôle. Si des paquets arrivent mais qu'aucune réponse ne repart, le rejet est local, dans ufw ou nftables.

Un ping qui échoue signifie-t-il que mon VPS est hors ligne ?

Non. De nombreux fournisseurs filtrent l'ICMP en bordure de réseau, donc un serveur qui traite normalement le trafic peut ignorer chaque ping que vous envoyez. Un ping réussi est tout aussi peu probant dans l'autre sens, car il n'indique pas si le port 22 est ouvert. Testez le port lui-même avec nc -vz -w 5 203.0.113.10 22 depuis votre propre machine, ou avec Test-NetConnection 203.0.113.10 -Port 22 dans PowerShell sur Windows.

J'ai changé le port SSH et plus rien ne se connecte. Que s'est-il passé ?

Deux erreurs de procédure causent cela. Si le pare-feu n'a jamais reçu de règle pour le nouveau port, les tentatives vers ce nouveau port expirent tandis que le port 22 refuse la connexion ; sudo ufw allow 2222/tcp doit donc être exécuté avant le changement de port, et non après. Si la machine utilise l'activation par socket systemd pour SSH, Port 2222 dans sshd_config est ignoré et systemd continue de maintenir l'ancien port, ce que vous pouvez confirmer avec systemctl is-enabled ssh.socket. Rétablissez l'accès via la console du fournisseur, corrigez le point concerné, puis connectez-vous avec ssh -p 2222 user@203.0.113.10 une fois que sudo ss -tlnp affiche le nouveau socket.