Temps de lecture : 12 min
Points clés à retenir
- Connection refused signifie que le serveur est joignable, mais que rien n’écoute sur le port 22.
- PowerShell permet de tester le port avec Test-NetConnection avant de toucher au serveur.
- Le pare-feu Windows peut bloquer PuTTY après une mise à jour ; une règle entrante ciblée suffit.
- OpenSSH est intégré à Windows 10 et 11, une alternative moderne à PuTTY.
Que signifie « Network error: Connection refused » dans PuTTY ?
L’erreur « Network error: Connection refused » apparaît lorsque PuTTY rejoint le serveur, mais qu’aucun service n’écoute sur le port indiqué. Cela signifie généralement que le serveur SSH (sshd) est arrêté, que le port est incorrect, ou qu’une règle de pare-feu bloque la connexion.
Cette erreur réseau PuTTY, souvent cherchée sous la forme putty network error connection refused, est un classique du dépannage SSH. Vous êtes sous Windows, PuTTY affiche ce message, et votre premier réflexe est de vous dire que le serveur est éteint. Détrompez-vous : le terme anglais refused signifie que la machine a répondu, mais qu’elle a refusé la connexion. C’est une distinction essentielle pour bien cibler le correctif.
Les trois causes immédiates sont faciles à retenir :
- Le démon SSH (sshd) est arrêté ou a planté après un redémarrage.
- Le port utilisé n’est pas le bon : le serveur écoute sur un autre port, par exemple 2222.
- Le pare-feu rejette la connexion, côté Windows, côté serveur, ou chez l’hébergeur.
Il ne faut pas confondre ce message avec un timeout. Connection refused signifie que le serveur a répondu par un rejet. Connection timed out signifie qu’aucune réponse n’est parvenue, souvent à cause d’un pare-feu qui laisse tomber les paquets ou d’un problème de routage. Le premier indique une machine joignable qui ne propose pas le service ; le second indique une machine injoignable.
Définition. « Connection refused » signifie que la demande TCP a été rejetée, contrairement au timeout qui indique une absence de réponse.

Étape 1 — Vérifier que le serveur SSH est bien démarré
Pour une erreur ssh connection refused windows, la première chose à faire est de vérifier que le démon SSH écoute réellement. Le message de refus indique qu’aucun service n’attend la connexion sur le port. La cause la plus fréquente ? Le service sshd est arrêté.
Vérifier le statut de sshd avec systemctl
Sur une distribution moderne, la commande la plus directe est :
sudo systemctl status sshd
Si la sortie indique Active: active (running), le service est démarré. Si elle affiche inactive (dead) ou failed, le démon ne tourne pas. Sur Ubuntu, le nom du service peut être ssh plutôt que sshd. Sur Debian, on trouve les deux. Sur CentOS ou RHEL, sshd reste la norme. L’important est de tester la bonne commande.
Pourquoi cette vérification d’abord ? Parce que le message « Connection refused » correspond souvent à un port fermé par l’absence de processus d’écoute. Un serveur allumé n’est pas un serveur SSH actif.
Redémarrer et activer le service SSH
Si le service est arrêté, lancez la commande de redémarrage adaptée à votre distribution. Voici un tableau récapitulatif utile :
| Distribution | Commande de statut | Commande de redémarrage |
|---|---|---|
| Ubuntu / Debian récent | sudo systemctl status ssh | sudo systemctl restart ssh |
| CentOS / RHEL 7 et plus | sudo systemctl status sshd | sudo systemctl restart sshd |
| SysV (Ubuntu 14.04, CentOS 6) | sudo service ssh status / sudo service sshd status | sudo service ssh restart / sudo service sshd restart |
Pensez aussi à activer le service au démarrage avec sudo systemctl enable ssh ou sudo systemctl enable sshd. Sans cette précaution, le serveur SSH ne redémarrera pas tout seul après un reboot. En résumé, si sshd ne tourne pas, PuTTY ne peut pas se connecter. Le correctif suivant va maintenant confirmer l’état du port depuis Windows.
Étape 2 — Tester l’ouverture du port 22 depuis Windows
Maintenant, passons à Windows. L’objectif est de vérifier si le port 22 est ouvert depuis votre poste. Cette étape s’appuie sur PowerShell, un outil très efficace pour diagnostiquer un serveur SSH. C’est aussi une excellente réponse à la question « comment vérifier si le port 22 est ouvert avec PowerShell ».
La commande PowerShell Test-NetConnection
Ouvrez PowerShell en mode administrateur, puis tapez :
Test-NetConnection 192.168.1.10 -Port 22
Remplacez l’adresse IP par celle de votre serveur. Le résultat contient la ligne TcpTestSucceeded. Si elle indique True, le port est accessible depuis Windows. Si elle indique False, le port est fermé ou bloqué.
| Commande | Résultat attendu | Interprétation |
|---|---|---|
| Test-NetConnection 192.168.1.10 -Port 22 | TcpTestSucceeded True | Le port 22 est joignable. |
| Test-NetConnection 192.168.1.10 -Port 22 | TcpTestSucceeded False | Le port est fermé ou un pare-feu bloque les paquets. |
| telnet 192.168.1.10 22 | Curseur visible | La connexion TCP aboutit. |
| telnet 192.168.1.10 22 | Message d’erreur | Le port est inaccessible. |
Le test rapide avec telnet
Si PowerShell n’est pas disponible, le client Telnet de Windows peut faire l’affaire. Ouvrez une invite de commandes et tapez telnet 192.168.1.10 22. Un curseur apparaît lorsque la connexion aboutit. Le message « Impossible d’ouvrir la connexion » signifie que le port est fermé.
Le test telnet utilise aussi le port 22, mais il ne remplace pas un vrai handshake SSH. Il confirme seulement que le port répond. Si le test échoue, le correctif suivant s’impose : le pare-feu.
Étape 3 — Contrôler le pare-feu Windows et celui du serveur
Si le port 22 est fermé, le pare-feu Windows peut être en cause. C’est particulièrement fréquent après une mise à jour Windows. Je me souviens d’un client dont PuTTY affichait « Network error: Connection refused » au lendemain d’une mise à jour. La mise à jour avait réinitialisé la règle du pare-feu. Il a suffi de recréer une règle entrante pour le port 22.
Créer une règle entrante pour le port 22
Pour configurer le pare-feu Windows pour PuTTY, la méthode la plus fiable est de créer une règle ciblée, pas de désactiver le pare-feu. En PowerShell administrateur :
New-NetFirewallRule -DisplayName 'SSH Port 22' -Direction Inbound -Protocol TCP -LocalPort 22 -Action Allow
Si vous préférez l’interface graphique, tapez wf.msc dans la fenêtre Exécuter. Ensuite :
- Cliquez sur Règles de trafic entrant.
- Choisissez Nouvelle règle.
- Sélectionnez Port, puis TCP et port 22.
- Autorisez la connexion et validez tous les profils.
Vérifier ufw et iptables côté serveur
Le pare-feu du serveur Linux peut également bloquer la connexion. Sur Ubuntu ou Debian, vérifiez avec UFW :
sudo ufw status
Si le port 22 n’apparaît pas, autorisez-le :
sudo ufw allow 22/tcp
Pour iptables, la commande suivante liste les règles entrantes liées au port 22 :
sudo iptables -L INPUT -n --line-numbers | grep :22
Avertissement : ne désactivez jamais entièrement le pare-feu Windows pour tester une connexion. Créez une règle ciblée pour le port 22, puis supprimez-la une fois le problème résolu.
Une fois le pare-feu corrigé, le port 22 devrait répondre. Si ce n’est toujours pas le cas, le problème peut se trouver dans la configuration de la session PuTTY elle-même.
Étape 4 — Vérifier la configuration de la session PuTTY
La cause est parfois plus simple qu’elle n’y paraît : la session PuTTY n’est pas configurée pour SSH. Le message connection refused peut alors être trompeur. Vérifiez chaque point avant de relancer la connexion.
- Protocole : sélectionnez SSH, pas Telnet.
- Port : 22 par défaut, ou le port indiqué dans la configuration du serveur.
- Adresse IP : vérifiez qu’il s’agit bien de l’adresse publique ou privée du serveur.
- Nom de session : sauvegardez la session après réglage pour éviter une erreur ultérieure.
Le piège le plus courant est d’avoir laissé le protocole Telnet sélectionné par défaut. Dans ce cas, PuTTY tente de rejoindre le port 23, qui n’est pas ouvert, et affiche un refus. La configuration SSH PuTTY paraît compliquée, mais elle tient en une ligne : hostname, port, protocole SSH.
Si cette configuration est correcte, le problème peut alors venir de PuTTY lui-même. Une solution moderne consiste à utiliser le client OpenSSH intégré à Windows.
Étape 5 — Utiliser OpenSSH dans Windows 10 et Windows 11
Depuis Windows 10 build 1809, OpenSSH est proposé comme fonctionnalité optionnelle. Vous pouvez donc délaisser PuTTY pour un client natif, plus simple, dans de nombreuses situations. C’est un correctif élégant quand la configuration PuTTY persiste à poser problème.
Installer le client OpenSSH
Pour activer OpenSSH sur Windows, ouvrez Paramètres > Applications > Fonctionnalités facultatives, cliquez sur Ajouter une fonctionnalité, puis choisissez Client OpenSSH. En PowerShell administrateur, la commande est :
Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0
Se connecter avec la commande ssh
Une fois le client installé, ouvrez PowerShell et tapez :
ssh utilisateur@192.168.1.10
La commande utilise le port 22 par défaut. Pour un autre port, ajoutez -p 2222. Cette méthode donne aussi accès à SCP pour transférer des fichiers, et s’appuie sur la même clé privée que PuTTY via l’agent SSH.
| Critère | PuTTY | Client OpenSSH |
|---|---|---|
| Interface | Graphique | Ligne de commande |
| Disponibilité | Téléchargement séparé | Intégré à Windows 10 et 11 |
| Gestion des clés | Page PuTTYgen dédiée | Commande ssh-keygen |
| Transfert de fichiers | PSFTP récent | SCP natif |
En résumé, OpenSSH est une alternative fiable à PuTTY. Si la connexion fonctionne avec ssh, le problème venait bien de la session PuTTY ou de son installation.
Étape 6 — Identifier les causes moins évidentes : fail2ban, IP bloquée, hébergement mutualisé
Si tout est vert, mais que PuTTY refuse toujours la connexion, pensez aux causes moins visibles. J’ai récemment aidé un client dont l’adresse IP publique avait changé après un redémarrage de sa box. Le serveur n’acceptait que l’ancienne adresse via une règle AllowUsers. Le résultat était un refus net. Une simple mise à jour de l’IP a tout réglé.
- fail2ban : après plusieurs échecs de connexion, votre adresse IP peut être bloquée. Vérifiez avec
sudo fail2ban-client status sshd. - Adresse IP publique modifiée : les box changent parfois d’IP au redémarrage. Comparez l’IP actuelle avec celle autorisée côté serveur.
- Serveur mutualisé : l’hébergeur peut restreindre SSH à certaines plages d’adresses IP ou désactiver le service. Contactez le support si nécessaire.
Cette cause de ssh connection refused serveur est souvent négligée. Pourtant, elle explique un grand nombre de blocages qui résistent aux tests réseau classiques.

Questions fréquentes
Pourquoi PuTTY affiche-t-il « connection refused » ?
Cela signifie que le port est joignable, mais qu’aucun service n’écoute, ou que le pare-feu rejette la connexion. Vérifiez sshd, le port et les règles du pare-feu.
Quelle est la différence entre « connection refused » et « connection timed out » ?
Le refus signifie que le serveur a répondu et a rejeté la connexion. Le timeout signifie qu’aucune réponse n’est parvenue, souvent à cause d’un pare-feu ou d’un problème réseau.
Comment savoir si le port 22 est ouvert sur un serveur ?
Utilisez Test-NetConnection dans PowerShell ou telnet depuis Windows, puis vérifiez l’écoute du port avec netstat côté serveur.
Comment activer OpenSSH sur Windows 11 ?
Accédez à Paramètres > Applications > Fonctionnalités facultatives, ajoutez Client OpenSSH, puis utilisez la commande ssh utilisateur@serveur.
Que faire si le service sshd est actif mais que la connexion est refusée ?
Contrôlez le port d’écoute dans sshd_config, les règles ufw et iptables, et vérifiez si fail2ban a bloqué votre adresse IP.
Puis-je utiliser PuTTY pour me connecter à un serveur Windows ?
Oui, si le serveur exécute OpenSSH Server. Installez la fonctionnalité OpenSSH Server et autorisez le port 22 dans le pare-feu Windows.
En résumé : la méthode en 8 correctifs pour rétablir votre connexion SSH
En résumé, résoudre l’échec de connexion SSH avec PuTTY sous Windows demande de suivre une progression logique. Ne sautez pas d’étape, chaque correctif apporte une information utile.
- Vérifier que le service sshd est démarré.
- Redémarrer et activer sshd au démarrage.
- Tester le port 22 avec Test-NetConnection.
- Créer une règle entrante dans le pare-feu Windows.
- Vérifier ufw et iptables côté serveur.
- Contrôler la session PuTTY : protocole, port, adresse IP.
- Utiliser OpenSSH dans Windows 10 ou 11.
- Vérifier fail2ban, l’IP publique et l’hébergeur.
Une fois la connexion rétablie, je vous recommande de sécuriser l’accès avec des clés SSH plutôt qu’un mot de passe. C’est plus sûr et plus confortable au quotidien. Et si le problème revient, vous saurez exactement par où commencer.





