SSH Connection Refused sur serveur Linux : 5 méthodes de diagnostic

Vous venez de déployer un VPS Linux tout neuf, ou il est 2 h du matin et votre monitoring hurle : SSH est down. Le terminal crache ssh: connect to host … port 22: Connection refused, et le pouls s'accélère. Pire : pas de VNC, pas de console cloud sous la main, juste un curseur qui clignote.

On voit ça plusieurs fois par mois. Parfois un junior modifie sshd_config et oublie le reload. Parfois le security group autorise 80 et 443 mais pas 22. Parfois fail2ban bannit discrètement l'IP de votre box après une salve de mauvaises tentatives. La bonne nouvelle : Connection refused se diagnostique en général — pas besoin de magie. Ce guide transforme les cinq chemins de dépannage les plus courants en checklist. Lisez d'abord l'erreur, puis avancez couche par couche. La plupart des causes apparaissent en vingt minutes.

Une hypothèse de départ : vous avez un autre moyen d'accès — console VNC cloud, accès série, ou une autre machine dans le même VPC. Si vous êtes totalement bloqué, allez directement à Quand vous êtes totalement bloqué.

Avant de dépanner : trois « impossible de se connecter » ne sont pas pareils

Beaucoup mélangent Connection refused, Connection timed out et Permission denied — puis courent après le mauvais problème pendant une heure. Selon la documentation officielle OpenSSH, chaque message pointe vers une couche différente de la pile :

Bien faire cette distinction fait gagner du temps. Connection refused veut dire que votre paquet est arrivé — le problème est côté serveur ou à sa frontière réseau immédiate. Timed out veut dire que quelque chose en chemin a avalé le trafic : modifier sshd_config sur une machine injoignable ne sert à rien tant que le chemin n'est pas réparé. Permission denied, c'est presque toujours identifiants, politique de compte ou ban IP après une session TCP déjà établie.

En équipe, collez la chaîne d'erreur exacte dans le canal d'incident. « SSH est cassé » invite douze suppositions ; « Connection refused sur le port 2222 depuis l'IP du bureau » réduit la recherche tout de suite.

Méthode 1 : Vérifier IP, DNS et accessibilité du port (couche réseau)

Avant d'accuser sshd, prouvez que la route est ouverte. Sur les VPS neufs, les coupables habituels : IP mal saisie, DNS pas encore propagé, ou sshd qui écoute sur un port non standard alors que vous tapez encore sur le 22.

Exécutez ceci depuis votre machine locale, dans l'ordre :

# 1. Confirm resolved IP is correct
                dig +short your.domain.com
                ping -c 3 your.server.ip

                # 2. Probe whether SSH port is open (replace 22 with your actual port)
                nc -zv your.server.ip 22
                # or
                telnet your.server.ip 22

                # 3. Connect with explicit port (avoids ~/.ssh/config surprises)
                ssh -p 22 -i ~/.ssh/id_ed25519 user@your.server.ip

Si nc renvoie Connection refused, les paquets atteignent le serveur — le souci est le service local ou le pare-feu local. Passez à la méthode 2. Si vous avez timed out ou que la sonde reste bloquée, priorisez le security group / Network ACL du cloud : la règle entrante autorise-t-elle le TCP sur 22 (ou votre port custom) ? La source est-elle 0.0.0.0/0, ou limitée par erreur à un sous-réseau privé ?

Vérifiez aussi votre propre réseau. VPN d'entreprise, réseaux universitaires et certains FAI filtrent le port 22. Basculer sshd temporairement sur 443 ou 2222 pour comparer est un classique : si le port alternatif marche, la cause est le filtrage sur le chemin — pas le serveur lui-même.

Quand vous gérez plusieurs hôtes, gardez une petite fiche des IP publiques et ports SSH. Les erreurs de copier-coller depuis un vieux ticket sont étonnamment fréquentes, surtout après migration chez le provider ou réattribution d'IP élastiques.

Pour l'accès par nom d'hôte, pensez TTL et cache. Vous avez peut-être mis à jour le DNS il y a cinq minutes, mais votre laptop ou le résolveur en amont pointe encore vers l'ancienne adresse. dig +short sur votre machine fait foi — pas l'interface du registrar.

Méthode 2 : Vérifier si le service sshd tourne

Une des causes les plus fréquentes de Connection refused : sshd n'a jamais démarré, ou le nom du service a changé après une mise à niveau OS. Sous Ubuntu/Debian l'unité s'appelle souvent ssh ; sous RHEL/CentOS/Rocky c'est sshd. Ne devinez pas — vérifiez avec les commandes.

Après connexion via VNC ou console cloud :

# Debian/Ubuntu
                sudo systemctl status ssh
                sudo systemctl start ssh
                sudo systemctl enable ssh

                # RHEL/CentOS/Rocky
                sudo systemctl status sshd
                sudo systemctl start sshd

                # Is it listening? Which address and port?
                sudo ss -tlnp | grep ssh
                # Expect 0.0.0.0:22 or [::]:22

                # Config syntax check (run after every edit)
                sudo sshd -t
                sudo systemctl reload ssh   # or sshd

Si systemctl status affiche failed, tirez les logs tout de suite : sudo journalctl -u ssh -n 50 --no-pager. Erreurs fatales typiques : typos dans la config, fichier HostKey manquant, ListenAddress lié à la mauvaise interface. Après chaque correction, toujours sshd -t avant reload — on a trop vu des reloads aveugles où sshd ne redémarre pas et vous vous enfermez dehors.

Sur des systèmes fraîchement réinstallés, confirmez qu'openssh-server est installé : sudo apt install openssh-server (famille Debian) ou sudo dnf install openssh-server (famille RHEL). Les images cloud minimales arrivent parfois sans serveur SSH.

Un disque plein peut aussi empêcher sshd de démarrer ou d'accepter des sessions. Un rapide df -h depuis la console vaut dix minutes de tête-à-queue à distance. Si quelqu'un a serré MaxStartups pendant une vague de brute-force, les clients légitimes peuvent voir du refused sous charge — cherchez les messages « drop connection » dans journalctl.

Quand plusieurs versions sshd coexistent après une mise à jour partielle, which sshd et le chemin ExecStart de l'unité doivent correspondre. Binaires et chemins de config décalés produisent des incidents « ça marchait hier » déroutants.

Méthode 3 : Inspecter le pare-feu hôte et les security groups cloud

sshd tourne, ss montre un listener, mais les clients ont encore refused — le suspect suivant : des règles pare-feu qui drop ou rejettent le trafic. Les serveurs Linux empilent souvent deux couches : security group cloud (extérieur de la NIC) et ufw/iptables/nftables dans l'OS (intérieur). Les deux doivent autoriser votre port SSH.

Vérifications courantes sur le système :

sudo ufw status verbose
                sudo ufw allow 22/tcp
                sudo ufw allow 2222/tcp   # if you changed the port
                sudo ufw reload

                # firewalld (CentOS, etc.)
                sudo firewall-cmd --list-all
                sudo firewall-cmd --permanent --add-service=ssh
                sudo firewall-cmd --reload

                # Inspect nftables/iptables directly
                sudo iptables -L INPUT -n -v

Les security groups cloud se modifient dans la console du fournisseur quand SSH est down — pas de CLI magique depuis le laptop. Trois détails : protocole TCP, plage de ports incluant votre port SSH, CIDR source pas limité par erreur à un seul hôte interne. Pour les tests, ouvrir temporairement à 0.0.0.0/0 convient ; resserrez sur l'IP de sortie du bureau une fois la connectivité confirmée.

Si Docker ou Kubernetes tourne sur le VPS, les règles iptables peuvent être réécrites automatiquement. Lancez sudo iptables-save | grep 22 et cherchez des DROP ou REJECT insérés avant ACCEPT. Pour l'exposition minimale et le compromis port SSH/HTTPS, voir notre FAQ décision pare-feu minimal Linux SSH/HTTPS.

L'IPv6 est un angle mort facile : vous corrigez l'IPv4 dans le security group pendant que ssh user@host préfère les enregistrements AAAA et tape un chemin v6 bloqué. Testez avec ssh -4 et ssh -6 quand le comportement semble incohérent.

Documentez quelle couche vous a bloqué. Les équipes qui ne corrigent que ufw et oublient le security group rejouent souvent la même panne au prochain « durcissement ».

Méthode 4 : Vérifier le port et les réglages sshd_config

Beaucoup d'admins déplacent SSH hors du port 22 ou fixent ListenAddress sur une interface interne seulement. Les clients qui tapent encore sur 22 verront refused. La config serveur est dans /etc/ssh/sshd_config. Directives clés (référence complète dans le manuel sshd_config) :

Port 2222
                # ListenAddress 0.0.0.0   # default: all interfaces; 127.0.0.1 blocks external access
                PermitRootLogin prohibit-password
                PasswordAuthentication no
                AllowUsers deploy admin

La séquence sûre pour changer de port : confirmer que le nouveau port écoute, mettre à jour le pare-feu, puis fermer l'ancien port. Pas en un seul geste téméraire — on a trop vu « passer de 22 à 2222 et fermer le 22 dans le security group tout de suite » verrouiller les gens avant validation du nouveau port.

Sous RHEL avec SELinux actif, après changement de port lancez sudo semanage port -a -t ssh_port_t -p tcp 2222 sinon sshd peut échouer au bind. AppArmor sur Ubuntu peut aussi restreindre des chemins ; les logs le disent clairement.

Côté client, revérifiez ~/.ssh/config pour un mauvais Port ou HostName. Avec des alias Host prod, copier une commande sans -p est une erreur récurrente.

AllowUsers et DenyUsers peuvent prêter à confusion : le TCP connecte, sshd répond, puis l'auth échoue — ou dans certains setups la connexion se coupe tôt. Si vous avez resserré la politique utilisateur récemment, comparez le nom d'utilisateur local avec ce que le serveur autorise.

Les jump hosts et ProxyJump ajoutent une variable. Un refused sur le dernier saut peut signifier que la bastion est OK mais pas le port ou le security group de la cible. Testez chaque segment avec nc et ssh -J.

Méthode 5 : Vérifier les bannissements IP (fail2ban / hosts.deny)

Si vous voyez Permission denied au lieu de refused mais que vous êtes sûr que la clé est bonne, suspectez un ban IP. fail2ban ajoute des règles iptables ou hosts.deny après des échecs de mot de passe répétés ou des handshakes bizarres. Le wiki fail2ban détaille la mécanique des jails.

Sur le serveur, inspectez :

# fail2ban status
                sudo fail2ban-client status sshd
                sudo fail2ban-client set sshd unbanip YOUR.CLIENT.IP

                # Classic hosts-based bans
                grep -v '^#' /etc/hosts.deny
                grep -v '^#' /etc/hosts.allow

                # Cloud "ops lock" or DDoS mitigation
                # → check provider console for security alerts or temporary IP blocks

Se bannir soi-même est courant : un script dérape, des dizaines de logins ratés en quelques secondes, fail2ban jette l'IP de sortie du bureau en jail. Après déban, ajoutez les IP admin dans ignoreip, ou coupez l'auth par mot de passe et ne gardez que les clés pour réduire les faux positifs.

Si vous faites tourner Jenkins, GitLab Runner ou des agents similaires qui SSH vers le VPS, des échecs d'enregistrement peuvent ressembler à des bizarreries SSH. En topologie hybride, le chemin réseau contrôleur–agent mérite son propre schéma — voir Topologie hybride Jenkins : contrôleur VPS + pool JNLP Mac cloud entreprise.

Cloudflare et autres proxies ne terminent pas SSH sur le port 22 comme le HTTP. Si vous avez mis le mauvais service devant ou confondu DNS bastion et DNS app, reculez et cartographiez quel hostname doit exposer SSH.

Totalement bloqué : emprunter la voie de secours

Si les cinq méthodes vous laissent dehors, essayez dans cet ordre :

• VNC cloud / console série — ne dépend pas de SSH ; connectez-vous et corrigez la config
• Rollback snapshot — si vous avez snapshotté avant le changement, restaurer bat une nuit blanche
• Mode single-user / image rescue — montez le disque d'origine, chroot, éditez sshd_config
• Ticket support — certains fournisseurs ouvrent temporairement un port ou lèvent un blocage

La leçon est simple : ne jamais faire des changements « qui pourraient me déconnecter » sur votre seule session SSH. Gardez un second terminal ouvert, utilisez tmux, et traitez pare-feu et sshd comme des opérations à haut risque.

Après récupération, écrivez un post-mortem en trois lignes : quoi a changé, quel signal vous avez manqué, quelle voie de secours vous a sauvé. Le prochain astreinte vous remerciera.

Checklist prévention : éviter la prochaine panique

Investissez dix minutes après l'incident — moins cher que la panique la prochaine fois :

• Login par clé, mots de passe désactivés ; ~/.ssh/authorized_keys en mode 600
• Port SSH non standard OK — changez security group et sshd_config ensemble
• Configurez fail2ban ignoreip pour les réseaux de confiance afin de ne pas bannir l'équipe
• Lancez sshd -t avant reload ; snapshot avant changements risqués
• Surveillez via un canal autre que « port SSH 22 up/down » seul — agent ou health checks réseau privé

Envisagez une bastion dédiée avec IP de sortie stable et security groups serrés sur les nœuds de prod. L'IP du café sur votre laptop ne devrait pas être la seule clé du royaume.