HardStacked →

SSH · pannes auto-infligées

Barré dehors de ton propre serveur : les cinq lock-outs SSH classiques

2026-07-19 · HardStacked · 6 min de lecture

Tu as changé une ligne dans sshd_config, tapé exit, et maintenant ton propre serveur refuse de te laisser entrer. Pas d'attaquant, pas de malware. Juste toi, un fichier de config, et une porte qui se barre de l'intérieur.

Presque tous les blocages SSH qu'on a vus se ramènent aux cinq mêmes erreurs. Chacune a l'habitude qui la rend survivable, et un filet de sécurité les couvre toutes.

1. Mot de passe désactivé, clé jamais testée

Le conseil est partout, et c'est un bon conseil : PasswordAuthentication no. Mais il suppose en silence que ta clé est installée et fonctionne vraiment. Si authorized_keys n'a jamais atterri sur le serveur, a les mauvaises permissions, ou contient un collage tronqué de ta clé publique, tu viens d'enlever la seule porte que tu pouvais ouvrir.

L'habitude

Prouve la connexion par clé depuis un deuxième terminal avant de couper les mots de passe, et garde ta première session ouverte. Si la nouvelle connexion entre sans demander de mot de passe, tu peux y aller.

2. Le pare-feu est monté avant la règle allow

$ sudo ufw default deny incoming $ sudo ufw enable ← le port 22 est fermé. Ta session survit ; la prochaine, non.

Celle-là est cruelle parce que tout a l'air correct. Ta connexion SSH courante est déjà établie, le pare-feu ne la coupe pas. Tout marche jusqu'à ce que tu te déconnectes, et après plus rien ne marche.

L'habitude

sudo ufw allow ssh avant sudo ufw enable, toujours dans cet ordre. Puis ouvre un nouveau terminal et reconnecte-toi avant de lui faire confiance.

3. fail2ban t'a banni, toi

Tu installes fail2ban pour tenir les bots dehors. Puis un matin tu échappes ta phrase de passe quelques fois, et le marteau de ban se fiche que ce soit toi. Les jails par défaut bannissent après environ cinq échecs. Et si tu te connectes derrière une adresse partagée ou un NAT d'opérateur, les échecs de quelqu'un d'autre peuvent compter dans ton ban.

L'habitude

Mets ta propre adresse dans ignoreip du jail.local. Déjà banni ? Les bans expirent (souvent 10 minutes à une heure). Depuis une autre adresse ou la console de l'hébergeur : fail2ban-client set sshd unbanip TON.IP.

4. Le changement de port que systemd a ignoré

Tu as mis Port 2222 dans sshd_config, ouvert 2222 dans le pare-feu, redémarré SSH. Et le serveur répond encore sur le 22, ou sur rien de ce que tu attendais. Sur Ubuntu 22.10 et plus récent, SSH est activé par socket : c'est le ssh.socket de systemd qui décide du port écouté, et selon la version il peut écraser en silence ce que sshd_config déclare.

L'habitude

Après tout changement de port, demande au noyau ce qui écoute vraiment, et crois-le avant n'importe quel fichier de config :

$ sudo ss -tlnp | grep sshd LISTEN 0 4096 *:22 users:(("sshd",...)) ← la vérité, peu importe la config

5. La typo qui explose des semaines plus tard

Un sshd_config invalide ne tue pas le démon qui roule ; il continue de servir avec l'ancienne config. L'échec attend le prochain restart. Souvent c'est un reboot des semaines plus tard, quand tu ne te souviens plus d'avoir édité quoi que ce soit, et sshd refuse simplement de démarrer.

L'habitude

Valide après chaque édition. Aucune sortie veut dire valide :

$ sudo sshd -t $ sudo systemctl reload ssh ← reload, pas restart, quand c'est possible

Les quatre règles de survie

  1. Ne ferme jamais ta session de travail tant que la nouvelle n'est pas prouvée. Les connexions établies survivent au restart de sshd ; ce terminal ouvert, c'est ta corde de rappel.
  2. Teste chaque changement avec une connexion neuve depuis un deuxième terminal.
  3. sshd -t avant, reload après.
  4. Trouve la console de secours de ton hébergeur aujourd'hui, avant d'en avoir besoin. Tout hébergeur sérieux en a une (console web, VNC, mode rescue). Ce n'est pas du SSH, donc elle marche encore quand SSH ne marche plus. Connecte-toi une fois maintenant, pour que le jour où ça compte ne soit pas le jour où tu l'apprends.

Déjà barré dehors ?

Respire : si le serveur est debout, tes données vont bien, et le chemin du retour c'est la console de secours mentionnée plus haut. Elle te donne un clavier sur la machine comme si tu étais planté devant. Connecte-toi là, annule ou répare le changement, roule sshd -t, redémarre SSH, et teste une vraie connexion SSH avant de sortir de la console.

La leçon de fond

Chaque changement risqué devrait avoir son chemin de retour préparé avant que le changement soit appliqué. Éditer à la main te laisse cette discipline sur les épaules, à 2 h du matin, sur une machine de production.

C'est le principe sur lequel HardVps est bâti : il capture l'original avant de toucher un fichier, chaque fix s'annule au bit près (vérifié SHA-256), et le seul fix qui pourrait te barrer dehors est opt-in derrière un avertissement explicite. Sur notre cycle de test complet sur un vrai VPS, SSH est resté debout à l'apply et au revert.

Voir ce que HardVps fait →

Sur un Raspberry Pi ? Commence gratuit avec audit-pi, notre audit de sécurité open-source.