PuTTY affiche Connection refused : corriger la panne

Dans PuTTY, le message « Network error: Connection refused » indique que l’ouverture de la connexion TCP a été rejetée. Le client n’a pas encore atteint l’étape du mot de passe ou de la clé SSH. Le rejet peut venir de la machine visée, mais aussi d’un pare-feu, d’une passerelle ou d’une redirection mal configurée : ce message ne prouve donc pas, à lui seul, que le bon serveur a répondu.

Procédez du client vers le serveur : relevez la destination, vérifiez le port, puis contrôlez l’écoute et le filtrage depuis une console indépendante. Ne redémarrez pas le serveur et ne modifiez pas le pare-feu « pour essayer ». Si vous n’avez pas de console de secours ou un accès déjà ouvert, arrêtez-vous avant toute modification côté serveur et demandez l’aide de l’administrateur.

Confirmez qu’il s’agit bien d’un refus TCP

Notez le texte exact affiché par PuTTY, l’heure de l’essai et la session utilisée. Dans le menu de la fenêtre PuTTY, ouvrez l’Event Log et relevez l’hôte, le port et la présence éventuelle d’un proxy. Masquez les noms internes et les adresses avant de transmettre ces informations. Le manuel PuTTY distingue explicitement Connection refused de Connection timed out.

• Connection refused : la tentative TCP reçoit un rejet, souvent un paquet RST. Le rejet peut être émis par l’hôte ou par un équipement intermédiaire configuré pour refuser.
• Connection timed out : aucune réponse utile n’arrive dans le délai. Un filtrage silencieux de type DROP, une route, une adresse erronée ou un équipement indisponible peuvent conduire à ce résultat. Ce n’est pas le même diagnostic ; le détail du timeout est réservé à un guide séparé.
• Server refused our key : la connexion SSH a atteint le stade de l’authentification par clé, mais le serveur n’accepte pas cette clé pour ce compte. Vérifiez alors les paramètres de clé et le compte ; consultez le guide pour utiliser une clé SSH avec PuTTY. Changer de clé ne corrigera pas un refus TCP initial.

Un ping ne permet pas de trancher : ICMP et le port TCP de SSH peuvent être filtrés différemment. Un ping sans réponse ne démontre donc pas que SSH est en panne, et un ping réussi ne valide pas le port SSH.

Vérifiez l’hôte et le port dans PuTTY

Dans PuTTY, chargez la session concernée et comparez ses champs aux informations fournies par l’hébergeur ou l’administrateur : Host Name doit contenir le nom ou l’adresse, sans préfixe https:// ; le type de connexion doit être SSH ; le port doit être le port SSH réellement publié. Ne supposez pas qu’il s’agit toujours du port 22. Si vous corrigez une valeur, enregistrez la session seulement après confirmation de la bonne destination. Pour les paramètres de base d’une session, reportez-vous au guide vérifier les paramètres de votre session PuTTY.

Depuis le PowerShell de Windows, remplacez le nom et le port d’exemple par ceux de votre session :

Resolve-DnsName serveur.example.net
Test-NetConnection -ComputerName serveur.example.net -Port 22 -InformationLevel Detailed

Resolve-DnsName affiche les adresses associées au nom ; comparez-les à la destination attendue. Test-NetConnection teste le port TCP indiqué : TcpTestSucceeded : True signifie que ce test a établi la connexion TCP, pas que l’identité du serveur ou l’authentification SSH sont validées. Une valeur False ne suffit pas à distinguer refus et délai dépassé : conservez le message PuTTY exact. Si PuTTY passe par un proxy ou un VPN, ce test direct peut emprunter un autre chemin ; les deux résultats ne sont alors pas directement comparables.

Depuis un client Linux que vous êtes autorisé à utiliser, vous pouvez aussi tester le seul port visé, si netcat est installé :

nc -vz -w 3 serveur.example.net 22

Remplacez les deux valeurs. Les options -z et -v demandent un test de connexion sans échange applicatif et un résultat lisible ; -w 3 borne l’attente à trois secondes. Les variantes de netcat diffèrent : si l’option n’est pas reconnue, consultez nc -h et adaptez-vous à la version installée, sans tester une plage de ports. Une connexion établie confirme l’accès TCP depuis ce client ; un refus appuie la piste du rejet ; une attente expirée ouvre une autre branche de diagnostic. Voir aussi le guide pour tester un port TCP avec netcat.

Contrôlez le service depuis une console Linux

Cette étape se fait dans la console de l’hébergeur, de la machine virtuelle ou devant le serveur, pas dans la session PuTTY qui échoue. Gardez cette console et toute session d’administration déjà ouverte : elles sont votre moyen de retour si une modification coupe l’accès. Le nom de l’unité dépend de la distribution et du mode de démarrage.

systemctl list-unit-files 'ssh*' --no-pager
sudo systemctl status ssh.service --no-pager
sudo systemctl status sshd.service --no-pager
sudo systemctl status ssh.socket --no-pager

La première commande inventorie les unités dont le nom commence par ssh. Contrôlez ensuite l’unité réellement présente : ssh.service est courant sur Debian et Ubuntu ; sshd.service l’est souvent sur Fedora et RHEL ; certains systèmes utilisent une activation par ssh.socket. « Unit not found » indique seulement que ce nom d’unité n’existe pas sur cette machine. Une unité active ne prouve pas que le port demandé écoute sur la bonne interface. Avec une activation par socket, systemd peut accepter la connexion et démarrer le service à la demande. Sur un système sans systemd, utilisez les outils de sa distribution au lieu de transposer ces commandes.

Si aucun serveur SSH n’est installé, confirmez d’abord avec l’administrateur que cette machine doit effectivement fournir SSH. Installer un paquet serveur n’est justifié que dans ce cas et selon la procédure de la distribution ; ce n’est pas une réparation universelle d’un mauvais port ou d’un rejet réseau.

Vérifiez le port et l’adresse d’écoute effective

Toujours depuis la console Linux, observez les interfaces, les sockets TCP en écoute et la configuration SSH :

ip -br address
sudo ss -ltnp
sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T

ip -br address montre les adresses locales ; un serveur derrière un NAT n’y affiche généralement pas son adresse publique. Dans ss -ltnp, -l limite l’affichage aux sockets en écoute, -t à TCP, -n garde les ports numériques et -p indique le processus lorsqu’il est disponible. Repérez le port attendu et le processus propriétaire, qui peut être systemd si le socket est activé.

Interprétez l’adresse aussi bien que le port. Une écoute sur 127.0.0.1:22 est limitée au bouclage local ; une adresse LAN précise ne couvre pas les autres interfaces. 0.0.0.0 désigne toutes les interfaces IPv4 ; une écoute sur [::] concerne IPv6 et ne garantit pas à elle seule l’accès IPv4. Si rien n’écoute sur le port auquel le trafic arrive, ne commencez pas par ouvrir le pare-feu : il n’y a alors aucun service sur cette destination.

sshd -t vérifie la syntaxe et les clés hôtes sans démarrer ni redémarrer le service. Une exécution valide ne produit normalement pas de message et renvoie un code de succès ; un message d’erreur doit être corrigé avant toute action sur le service. sshd -T affiche la configuration effective après lecture et validation, notamment les valeurs de port et d’adresse d’écoute. Ne diffusez pas sa sortie complète sans la relire et masquer les détails sensibles. Le manuel officiel décrit les options sshd(8) et les directives Port et ListenAddress. Ces pages documentent OpenSSH ; les chemins et unités varient selon Linux. Sur une configuration utilisant ssh.socket, confrontez aussi les résultats de ss à l’unité active : la sortie de sshd -T seule ne prouve pas ce que la socket systemd expose réellement.

Ne modifiez Port ou ListenAddress qu’après avoir identifié un mauvais réglage et sauvegardé la configuration concernée. Confirmez quelle interface doit être accessible ; n’élargissez pas l’écoute à toutes les interfaces par défaut. Avant toute modification ou recharge, gardez la console de secours et l’accès existant ouverts. Ubuntu rappelle les précautions liées à la configuration du serveur dans sa documentation OpenSSH Server.

Comparez le filtrage local, le réseau et le NAT

Si le port écoute sur la bonne interface mais que le test externe est refusé, identifiez d’abord le gestionnaire de pare-feu réellement utilisé et le chemin du trafic. Les commandes ci-dessous sont en lecture seule : n’exécutez que celle qui correspond à votre système.

sudo ufw status verbose
sudo nft list ruleset
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=public --list-all

UFW, nftables et firewalld ne sont pas interchangeables. Une commande absente ne prouve pas qu’il n’y a aucun filtrage. Avec firewalld, public est seulement un exemple de zone : identifiez la zone associée à l’interface, puis examinez les règles, leur ordre, le protocole TCP, le port, les sources autorisées et les actions de rejet. Ne combinez pas plusieurs gestionnaires pour appliquer des changements et ne désactivez pas le pare-feu pour tester.

Vérifiez ensuite, en lecture seule, les règles du pare-feu cloud ou de l’hébergeur : port publié, protocole et adresses sources autorisées. Si le serveur est derrière un routeur, contrôlez la redirection du port externe vers la bonne adresse privée et le port réellement en écoute. Par exemple, une redirection conceptuelle du port externe 2222 vers le port interne 22 implique que PuTTY se connecte au port 2222 depuis Internet, tandis que ss affiche le port 22 sur le serveur. Vérifiez aussi que l’adresse privée de la machine n’a pas changé. Si un VPN ou un bastion est prévu, privilégiez ce chemin plutôt que d’exposer SSH à tout Internet.

Un test depuis le même réseau local vers l’adresse publique dépend de la prise en charge du NAT loopback par le routeur ; il ne remplace pas un test extérieur autorisé. Une absence de réponse liée au routage, à une adresse publique ou à du CGNAT conduit souvent vers la branche du timeout : n’essayez pas de la contourner en ouvrant des ports sans validation.

Appliquez une seule correction prouvée, puis retestez

• Hôte ou port erroné dans la session : corrigez uniquement la destination client confirmée par l’administrateur.
• Service absent alors que SSH doit être fourni : faites valider l’installation et l’activation selon la distribution.
• Service arrêté, configuration valide, unité correcte et accès console assuré : un démarrage contrôlé peut être approprié.
• Adresse d’écoute incorrecte : corrigez seulement le bind confirmé et vérifiez d’abord la configuration.
• Règle de rejet démontrée : demandez ou appliquez une règle limitée au port SSH, au protocole et aux sources nécessaires.
• Redirection erronée : corrigez la destination privée ou le port externe après confirmation du trajet attendu.

Pour un service systemd réellement arrêté, uniquement si le serveur doit fournir SSH, si sshd -t a réussi, si l’unité est bien celle utilisée et si la console de secours est accessible, le démarrage contrôlé peut être :

sudo systemctl start ssh.service

Remplacez ssh.service par sshd.service si c’est l’unité présente ; ne lancez pas les deux et ne démarrez pas un service en concurrence avec une socket d’activation. Cette commande change l’état de la machine : elle ne doit pas servir de premier test. Après une modification de configuration, vérifiez d’abord le mécanisme de rechargement pris en charge par votre distribution et son unité ; aucun redémarrage automatique n’est recommandé ici. La documentation officielle Ubuntu rappelle qu’une modification SSH peut verrouiller l’accès : conservez donc la session ouverte et la console de secours pendant le contrôle.

Après chaque correction, procédez séparément : relisez ss -ltnp côté serveur, puis ouvrez une nouvelle fenêtre PuTTY vers l’hôte et le port corrigés. Si PuTTY présente une nouvelle empreinte d’hôte, vérifiez-la par un canal fiable avant de l’accepter. Atteindre la bannière SSH ou l’écran d’authentification signifie que le refus TCP est levé ; cela ne signifie pas que le compte est déjà authentifié. Gardez l’accès de secours tant que cette nouvelle connexion n’a pas abouti.

N’utilisez pas ufw disable, nft flush ruleset ou iptables -F. N’ouvrez pas SSH globalement sans restriction de source, ne contournez pas le problème en activant la connexion root et n’affaiblissez ni les permissions SSH ni l’authentification multifacteur.

Consultez les journaux si le refus persiste

Depuis la console Linux, choisissez l’unité réellement présente et examinez une fenêtre récente autour de l’heure notée dans PuTTY :

sudo journalctl -u ssh.service -n 50 --no-pager
sudo journalctl -u sshd.service -n 50 --no-pager
sudo journalctl -u ssh.socket -n 50 --no-pager

Ne lancez que la commande correspondant à l’unité existante. Recherchez une erreur de configuration, une adresse indisponible ou un port déjà occupé. Selon la distribution et sa journalisation, des fichiers comme /var/log/auth.log ou /var/log/secure peuvent compléter le journal ; ils ne sont pas présents partout. Un refus avant l’établissement de SSH peut ne laisser aucune entrée d’authentification. De même, un rejet par un routeur ou un pare-feu cloud peut ne pas apparaître dans journalctl : l’absence de ligne ne prouve pas l’absence de tentative.

Si vous administrez le serveur et disposez de tcpdump, une capture très courte peut aider à localiser le rejet. Remplacez l’adresse de documentation par l’adresse source effectivement vue au serveur, qui peut différer après NAT ; ne capturez que sur une machine et un réseau que vous êtes autorisé à diagnostiquer.

sudo timeout 10 tcpdump -ni any -c 20 'tcp port 22 and host 192.0.2.10'

timeout 10 borne la capture à dix secondes ; -c 20 l’arrête après vingt paquets au maximum ; -n évite la résolution de noms et -i any écoute les interfaces disponibles. L’exemple vise le port interne 22 : adaptez le filtre au port observé. Un SYN entrant suivi d’un RST sur ce point de capture étaye un rejet à cet endroit, sans identifier automatiquement l’équipement responsable. Aucun paquet capturé peut aussi résulter d’une mauvaise interface, d’un mauvais filtre ou d’un autre chemin réseau. Ne capturez pas le contenu avec des options de décodage de charge utile, ne conservez pas un fichier de capture permanent et masquez les adresses et horaires avant de partager les résultats.

Si vous n’avez ni console indépendante ni autorisation pour inspecter le pare-feu, ne poursuivez pas les modifications à distance. Transmettez à l’administrateur l’hôte et le port visés, l’heure, le message PuTTY exact et les tests effectués, après avoir expurgé les informations internes.