J'ai activé ufw et maintenant SSH ne se connecte plus. Le serveur est perdu ?

Non. Le serveur tourne parfaitement — vous avez juste fermé la porte de l'intérieur. Vos données sont intactes. Ouvrez la console web du panneau (elle entre sans SSH) et lancez `sudo ufw disable` ; vous êtes de nouveau dedans. Pas besoin de réinstaller.

Pourquoi activer ufw a-t-il coupé mon SSH ?

ufw refuse tout le trafic entrant par défaut, et si vous l'activez sans d'abord autoriser votre port SSH, votre propre session est coupée. C'est l'auto-enfermement le plus courant. Toujours `ufw allow ` avant `ufw enable`.

Comment réparer ufw si je ne peux plus du tout entrer en SSH ?

Utilisez la console web hors bande (console série) du panneau : elle ne passe pas par SSH ni même par la pile réseau, donc une règle de pare-feu ne peut pas la bloquer. Connectez-vous, puis `sudo ufw disable` (le plus rapide) ou `sudo ufw allow ` pour corriger la règle précise.

Sur un VPS en NAT, quel port autoriser dans ufw ?

Autorisez le 22, pas le port externe. En NAT vous vous connectez sur un port élevé comme 20266, mais il est redirigé vers le port 22 à l'intérieur de la VM. ufw tourne dans la VM et ne voit que le 22. Autoriser 20266 ne fait rien — autorisez le 22.

`ufw reset` est-il plus sûr que `ufw disable` ?

`disable` éteint juste le pare-feu et garde vos règles — le retour le plus rapide. `reset` efface toutes les règles aux valeurs par défaut. Pour récupérer, utilisez `disable`, puis ré-ajoutez les règles avec soin. `reset` seulement si le jeu de règles est un fouillis à supprimer.

Enfermé hors de votre VPS par ufw ? Revenez sans réinstaller

Il y a un rite de passage pour quiconque débute avec son propre serveur : vous décidez de configurer un pare-feu, vous tapez quelques commandes ufw, vous faites enable — et le terminal devient muet. SSH a disparu. Vous n'avez rien cassé et vous n'avez pas été piraté. Vous avez juste fermé la porte, vous dehors.

Ça arrive aussi aux bons administrateurs. La semaine dernière c'est arrivé à l'un de nos clients, d'où cet article. La bonne nouvelle : ça se récupère entièrement en moins d'une minute, et vous n'avez pas besoin de réinstaller ni de perdre un seul fichier. Voici comment.

Un serveur scellé derrière un mur de pare-feu, avec une fenêtre de console lumineuse comme voie de retour

Ce qui a vraiment mal tourné

ufw (Uncomplicated Firewall) refuse tout l'entrant par défaut. À l'instant où vous lancez ufw enable, tout ce que vous n'avez pas explicitement autorisé est rejeté — y compris la session SSH dans laquelle vous êtes assis. Si vous avez oublié d'ufw allow votre port SSH d'abord, vous avez coupé votre propre connexion dès que la règle a pris effet.

C'est la version classique. Deux autres piègent aussi les gens :

Vous avez autorisé le mauvais port. Une faute de frappe, ou vous avez autorisé le port du service (disons 8080) en oubliant le 22.
Vous avez autorisé le 22 mais placé une règle deny plus haut dans la liste qui le masque. ufw est sensible à l'ordre.

Dans tous les cas le serveur lui-même va bien — il tourne, disque intact, votre appli ronronne toujours derrière le mur. C'est purement un problème d'accès réseau. Et c'est justement pour ça que la réparation est simple.

Le mauvais geste : réinstaller

Le premier réflexe est souvent « je réinitialise le serveur et je repars de zéro ». Ne le faites pas — pas pour ça. Réinstaller efface tout pour récupérer un SSH fonctionnel, alors que ce qui bloque le SSH est une commande de pare-feu que vous annulez en dix secondes. C'est brûler la maison parce que vous avez claqué la porte d'entrée.

Réinstaller est le bon choix quand vous voulez une page blanche. Pour un blocage ufw, c'est démesuré.

Le bon geste : la console web

Tout VPS digne de ce nom vous donne une console hors bande — un accès à la machine qui ne passe pas par SSH ni même par la pile réseau. Chez EQVPS c'est le bouton Console sur la page de votre serveur. C'est une console série : texte uniquement, branchée directement sur la VM comme le seraient un écran et un clavier. Une règle de pare-feu n'a aucun pouvoir dessus, car ce n'est pas du trafic réseau.

Cliquez, connectez-vous avec vos identifiants root (ou révélez le mot de passe dans le panneau si vous ne l'avez pas sous la main) — et vous êtes sur la machine, pare-feu ou pas.

Maintenant, défaites les dégâts. La voie la plus rapide :

sudo ufw disable

Ça éteint le pare-feu et garde vos règles, pour pouvoir le réactiver plus tard une fois l'erreur corrigée. Le SSH revient aussitôt.

Si vous préférez ne pas couper le pare-feu entièrement, ouvrez juste le port que vous aviez manqué :

sudo ufw allow 22
sudo ufw status numbered

status numbered vaut le coup d'œil : il montre l'ordre des règles — c'est là que se cachent les cas « j'ai autorisé le 22 et ça bloque quand même ». Si un deny se trouve au-dessus de votre allow, supprimez-le avec sudo ufw delete <numéro>.

Le piège NAT que presque aucun guide ne mentionne

Si vous êtes sur un plan NAT, il y a un piège ici. Vous vous connectez en SSH sur un port élevé — genre 20266 — donc le réflexe naturel est ufw allow 20266. Ça ne fait rien.

En NAT, ce port externe est redirigé vers le port 22 à l'intérieur de la VM. ufw tourne dans la VM et ne voit jamais que le 22. La règle dont vous avez réellement besoin est donc :

sudo ufw allow 22

Autorisez 20266 et vous fixerez une connexion toujours cassée en vous demandant pourquoi. Autorisez le 22 et vous êtes dedans. Même logique pour tout service : autorisez le port que le processus écoute à l'intérieur de la machine, pas le port redirigé par lequel vous vous connectez de l'extérieur.

Comment ne plus jamais le refaire

La réparation prend une minute, mais ne pas en avoir besoin, c'est mieux. Deux habitudes :

Autorisez votre port SSH avant d'activer. Toujours dans cet ordre :

sudo ufw allow 22
sudo ufw enable

Faites l'inverse et vous repartez pour la console.

Gardez une seconde session SSH ouverte pendant que vous modifiez les règles du pare-feu. Connectez-vous deux fois. Faites vos changements dans une fenêtre ; si le SSH meurt, l'autre est encore vivante pour réparer. Vieux truc, il vous sauve à chaque fois.

Et si vous montez une machine neuve, notre checklist de sécurité pour un nouveau VPS couvre ufw dans le bon ordre, avec les clés SSH et les quelques autres choses qui comptent vraiment dans les dix premières minutes.

À retenir

Un blocage ufw fait peur et n'est presque rien. Le serveur n'est jamais parti ; il vous faut juste une porte qu'aucun pare-feu ne peut claquer — la console web — et une commande. Gardez ufw disable et la console dans votre poche, autorisez votre port avant d'activer la prochaine fois, et ce truc ne vous fera plus jamais transpirer.