Ubuntu 24.04 : UFW vous a verrouillé — récupérer l’accès SSH en toute sécurité depuis la console

janvier 1, 2026 • février 3, 2026 • Lecture : 24 min • Views: 11

Cet article vous a aidé ?

Vous avez activé UFW (ou « renforcé » ses règles), votre session SSH a sauté et maintenant le port 22 semble en grève silencieuse. Vous pouvez toujours atteindre le serveur via une console hyperviseur, une console série cloud, KVM/iDRAC ou toute autre ligne de vie hors bande que vous avez. Bien. C’est suffisant.

Ceci est la méthode console-only, sûre pour la production, pour récupérer SSH sans transformer votre pare-feu en papier toilette humide. Nous diagnostiquerons d’abord, modifierons une chose à la fois et laisserons le système plus fiable qu’à l’origine. Parce que revenir n’est que la moitié du travail ; éviter la répétition de l’incident est l’autre moitié.

Règles de base : ne pas aggraver la situation

Quand vous êtes verrouillé, l’envie est de « simplement désactiver le pare-feu ». Parfois c’est le levier d’urgence approprié. Mais en production, soyez délibéré, car la même erreur qui a bloqué SSH peut aussi ouvrir accidentellement des bases de données, des panneaux d’administration ou des services internes vers Internet.

Voici l’ensemble de règles que j’applique :

La console est votre plan de contrôle. Gardez une session console ouverte jusqu’à ce que vous ayez une nouvelle session SSH confirmée. Ne fermez pas votre seul parachute en plein saut.
Privilégiez les changements additifs. Ajoutez une règle allow aussi restreinte que possible avant de supprimer des deny ou de réinitialiser UFW.
Validez le chemin réseau. Le pare-feu peut être innocent. Mauvaise interface, mauvaise IP, sshd arrêté, problèmes de routage, security groups cloud — plein de suspects.
Rendez les changements réversibles. Utilisez des commentaires, notez l’heure, conservez une copie des sorties avant/après.

Une citation que je garde collée sur le tableau de bord mental : « L’espoir n’est pas une stratégie. » — General Gordon R. Sullivan. Elle s’applique au travail sur les pare-feu plus qu’on ne veut l’admettre.

Faits intéressants et contexte historique (oui, ça compte)

Les pare-feux sont une technologie ancienne avec de nouveaux habillages. Savoir ce qu’il y a sous UFW vous aide à éviter le débogage fondé sur la superstition.

UFW est une interface, pas le pare-feu lui‑même. Il écrit des règles dans le filtrage noyau — historiquement iptables, et de plus en plus nftables sur les Ubuntu modernes.
iptables a été la valeur par défaut pendant des années. Beaucoup de tutoriels « classiques » supposent des chaînes et des sorties iptables qui ne correspondent pas aux systèmes basés sur nft.
nftables est arrivé pour unifier IPv4/IPv6 et simplifier la gestion des règles. Ce n’est plus « nouveau », mais pas mal de runbooks continuent de faire comme si.
Le port par défaut de SSH (22) est une convention, pas une loi. Le « security-through-port-hopping » réduit surtout du bruit dans les logs, ce n’est pas un vrai contrôle d’accès.
Les politiques par défaut d’UFW sont une arme chargée. « Default deny incoming » est correct pour des serveurs, mais il rejettera des flux existants auxquels vous n’avez pas pensé.
Les verrouillages IPv6 sont courants. On autorise IPv4 sur 22 et on oublie IPv6 ; les clients qui préfèrent IPv6 échoueront « mystérieusement ».
Les pare-feux cloud précèdent UFW sur votre chemin de requête. Les security groups / NACL peuvent vous bloquer bien avant que le paquet n’atteigne votre noyau.
Le filtrage stateful explique pourquoi les sessions existantes survivent parfois. Conntrack peut maintenir une session SSH établie vivante tandis que les nouvelles échouent — jusqu’à ce que vous vous déconnectiez et le regrettiez.
UFW peut être activé avec des règles manquantes. L’outil ne lit pas dans vos pensées ; il appliquera volontiers « deny » pendant que vous êtes encore en train de taper « allow ».

Mode opératoire de diagnostic rapide

C’est la route la plus rapide vers le goulet d’étranglement. Suivez-la dans l’ordre. Le but est d’éviter de modifier la mauvaise couche.

Première étape : confirmer que sshd est vivant et écoute là où vous pensez

Est-ce que sshd tourne ?
Écoute-t-il sur le port attendu et sur les adresses attendues (0.0.0.0 vs une IP spécifique) ?
L’avez-vous lié accidentellement à localhost ou à une interface interne ?

Deuxième étape : confirmer que le réseau hôte est sain

Bonne IP sur la bonne interface ?
Route par défaut présente ?
Pouvez-vous atteindre votre passerelle ?

Troisième étape : confirmer la couche de pare-feu qui rejette réellement les paquets

Changements des security groups du cloud / pare-feu fournisseur ?
État d’UFW et règles actives ?
Les règles nftables/iptables sous-jacentes sont-elles cohérentes avec la sortie UFW ?

Quatrième étape : réparer avec un rayon d’action minimal

Ajoutez un allow temporaire depuis votre IP de gestion (ou sous‑réseau).
Vérifiez que vous pouvez ouvrir une nouvelle session SSH.
Puis nettoyez et durcissez.

Vérité sèche et drôle #1 : Le pare-feu ne « vous en veut » jamais personnellement ; il applique simplement ce que vous lui avez dit, y compris la partie que vous n’aviez pas l’intention de.

Récupération depuis la console : restaurer SSH en toute sécurité

Nous partons du principe que vous avez un accès console (physique, IPMI/iDRAC, console hyperviseur, console série cloud). Vous êtes connecté en tant qu’utilisateur avec sudo ou en root.

L’approche la plus sûre est :

Confirmer que sshd tourne et écoute.
Confirmer quelle adresse/port vous voulez autoriser (souvent le port 22, parfois un port non standard).
Ajouter la règle UFW la plus restrictive possible pour SSH depuis une source de confiance.
Vérifier avec les logs et une tentative SSH réelle.
Ce n’est qu’ensuite que vous devez supprimer les exceptions d’urgence ou les règles plus larges.

Si vous ne connaissez pas votre IP de gestion (ça arrive), utilisez un allow temporaire plus large sur votre réseau interne ou la plage VPN, pas 0.0.0.0/0, et mettez un rappel pour restreindre ensuite. « Temporaire » sans suite est la naissance des tickets de sécurité.

Tâches pratiques (commandes, sorties, décisions)

Ci‑dessous des commandes réelles et exécutables. Chaque tâche inclut : ce que vous exécutez, ce que la sortie signifie et la décision suivante. Exécutez-les depuis la console sur l’hôte affecté.

Task 1: Confirm you are on the host you think you’re on

cr0x@server:~$ hostnamectl
 Static hostname: server
       Icon name: computer-server
         Chassis: server
      Machine ID: 7e3c0f0d3a1c4b3a9c1d2f3a4b5c6d7e
         Boot ID: 2b1d2c3e4f5a6b7c8d9e0f1a2b3c4d5e
Operating System: Ubuntu 24.04.1 LTS
          Kernel: Linux 6.8.0-36-generic
    Architecture: x86-64

Signification : Confirme la version d’OS et le noyau ; Ubuntu 24.04 implique qu’UFW peut utiliser un backend nftables selon le packaging/config.

Décision : Procédez en supposant que les outils modernes nft peuvent être pertinents ; ne copiez pas bêtement des formules iptables de 2016.

Task 2: Check whether SSH is running

cr0x@server:~$ systemctl status ssh --no-pager
● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/usr/lib/systemd/system/ssh.service; enabled; preset: enabled)
     Active: active (running) since Sat 2025-12-28 09:07:12 UTC; 21min ago
       Docs: man:sshd(8)
             man:sshd_config(5)
   Main PID: 1123 (sshd)
      Tasks: 1 (limit: 18763)
     Memory: 3.6M (peak: 4.2M)
        CPU: 72ms
     CGroup: /system.slice/ssh.service
             └─1123 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups

Signification : sshd est en cours d’exécution. S’il était inactif/failed, le pare-feu ne serait pas votre principal problème.

Décision : S’il est inactif, corrigez sshd d’abord (config, clés, port). S’il est actif, passez aux sockets d’écoute.

Task 3: Verify what port/address sshd is listening on

cr0x@server:~$ ss -ltnp | grep -E '(:22|:2222)\s'
LISTEN 0      128          0.0.0.0:22        0.0.0.0:*    users:(("sshd",pid=1123,fd=3))
LISTEN 0      128             [::]:22           [::]:*    users:(("sshd",pid=1123,fd=4))

Signification : SSH écoute sur le port 22 en IPv4 et IPv6. Si vous ne voyez que 127.0.0.1:22 ou une IP d’interface spécifique, l’accès distant peut échouer quelle que soit la configuration UFW.

Décision : Si l’écoute semble correcte, concentrez-vous sur le pare-feu et le filtrage en amont. Sinon, corrigez /etc/ssh/sshd_config (par ex. ListenAddress, Port) et rechargez.

Task 4: Confirm your IP and default route

cr0x@server:~$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
ens3             UP             203.0.113.10/24 2001:db8:1234:5678::10/64

cr0x@server:~$ ip route
default via 203.0.113.1 dev ens3 proto static
203.0.113.0/24 dev ens3 proto kernel scope link src 203.0.113.10

Signification : L’interface est up, l’IP existe, la route par défaut existe.

Décision : Si la route par défaut manque, corrigez le réseau d’abord ; UFW ne résoudra pas un « no route to host ».

Task 5: See whether UFW is even enabled

cr0x@server:~$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp                     DENY IN     Anywhere
22/tcp (v6)                DENY IN     Anywhere (v6)

Signification : UFW est actif et refuse explicitement SSH. C’est votre verrouillage.

Décision : Ne réinitialisez pas tout. Ajoutez une règle allow limitée au-dessus de ce deny, ou supprimez le deny s’il est accidentel (après avoir vérifié ce qui l’a créé).

Task 6: Inspect numbered rules so you can surgically fix them

cr0x@server:~$ sudo ufw status numbered
Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     DENY IN     Anywhere
[ 2] 22/tcp (v6)                DENY IN     Anywhere (v6)

Signification : Vous pouvez supprimer par numéro de règle sans deviner la syntaxe.

Décision : Si le deny est manifestement erroné, supprimez-le. Si vous n’êtes pas sûr, ajoutez d’abord un allow depuis l’IP de gestion, puis supprimez.

Task 7: Add a temporary allow from your management IP (recommended)

cr0x@server:~$ sudo ufw allow from 198.51.100.25 to any port 22 proto tcp comment 'TEMP: restore SSH from mgmt IP'
Rule added

Signification : Cela crée une règle allow plus spécifique. UFW ordonne généralement les règles de façon à ce que les règles spécifiques puissent prévaloir.

Décision : Tentez une connexion SSH depuis 198.51.100.25. Si ça marche, vous avez restauré l’accès avec une exposition minimale.

Task 8: Verify rule ordering and effective policy

cr0x@server:~$ sudo ufw status numbered
Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     ALLOW IN    198.51.100.25
[ 2] 22/tcp                     DENY IN     Anywhere
[ 3] 22/tcp (v6)                DENY IN     Anywhere (v6)

Signification : L’allow est évalué avant le deny pour IPv4. IPv6 est toujours globalement refusé, ce qui est acceptable si votre chemin de gestion est IPv4-only.

Décision : Si vos clients se connectent via IPv6, vous devez aussi autoriser IPv6 depuis votre préfixe de gestion ou désactiver la préférence IPv6 côté client (temporaire) pendant que vous corrigez les règles.

Task 9: Check UFW logging for dropped SSH packets

cr0x@server:~$ sudo journalctl -k -g 'UFW BLOCK' --since '10 minutes ago' --no-pager | tail -n 5
Dec 28 09:26:03 server kernel: [UFW BLOCK] IN=ens3 OUT= MAC=aa:bb:cc:dd:ee:ff SRC=203.0.113.50 DST=203.0.113.10 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=54321 DF PROTO=TCP SPT=51514 DPT=22 WINDOW=64240 RES=0x00 SYN URGP=0

Signification : Les paquets atteignent l’hôte et sont bloqués par UFW. C’est une bonne nouvelle : le routage en amont et les pare-feu du fournisseur ne sont probablement pas le goulet.

Décision : Corrigez les règles UFW, pas les security groups cloud.

Task 10: Confirm what backend is active (nftables vs iptables) and inspect raw rules

cr0x@server:~$ sudo ufw show raw | head -n 25
*filter
:ufw-user-input - [0:0]
:ufw-user-output - [0:0]
:ufw-user-forward - [0:0]
:ufw-before-input - [0:0]
:ufw-before-output - [0:0]
:ufw-before-forward - [0:0]
:ufw-after-input - [0:0]
:ufw-after-output - [0:0]
:ufw-after-forward - [0:0]
:ufw-logging-deny - [0:0]
:ufw-logging-allow - [0:0]
:ufw-reject-input - [0:0]
:ufw-reject-output - [0:0]
:ufw-reject-forward - [0:0]
-A ufw-user-input -p tcp --dport 22 -s 198.51.100.25 -j ACCEPT
-A ufw-user-input -p tcp --dport 22 -j DROP
COMMIT

Signification : Vous voyez la logique réelle accept puis drop. C’est la vérité sur disque.

Décision : Si la vue brute ne correspond pas à ufw status, vous pouvez avoir une application partielle ou un autre gestionnaire de pare-feu qui interfère. Enquêtez avant d’ajouter d’autres règles.

Task 11: Remove the accidental deny rule (surgical fix)

cr0x@server:~$ sudo ufw delete 2
Deleting:
 allow 22/tcp
Proceed with operation (y|n)? y
Rule deleted

Signification : Vous avez supprimé la règle #2 selon la numérotation actuelle. (Oui, la numérotation change quand on ajoute/supprime. Toujours revérifier.)

Décision : Si vous avez l’intention d’autoriser SSH de façon générale, remplacez le deny par un allow vers votre CIDR admin, VPN ou bastion — pas « Anywhere » sauf si vous avez une bonne raison et d’autres contrôles.

Task 12: Set a sane SSH policy (choose your poison, but choose one)

Option A : autoriser SSH seulement depuis un sous‑réseau de gestion (meilleur pour la plupart des serveurs de production) :

cr0x@server:~$ sudo ufw allow from 198.51.100.0/24 to any port 22 proto tcp comment 'SSH from mgmt subnet'
Rule added

Option B : autoriser SSH depuis n’importe où (acceptable pour des bastions avec authentification forte et surveillance) :

cr0x@server:~$ sudo ufw allow 22/tcp comment 'SSH'
Rule added

Signification : Vous exprimez une intention. UFW est heureux quand les règles reflètent les vrais schémas d’accès.

Décision : Si vous choisissez « Anywhere », compensez par une configuration SSH forte (clés seulement, pas de root login, contrôle de type fail2ban, et bons logs).

Task 13: Handle IPv6 explicitly (because your client will)

cr0x@server:~$ sudo ufw status verbose | grep -E 'IPv6|v6'
22/tcp (v6)                DENY IN     Anywhere (v6)

cr0x@server:~$ sudo ufw allow from 2001:db8:9999::/48 to any port 22 proto tcp comment 'SSH from mgmt IPv6'
Rule added

Signification : Les règles IPv6 sont des entrées séparées. Si vous utilisez IPv6, traitez‑le comme une première classe.

Décision : Si vous n’utilisez pas du tout IPv6, ne laissez pas des politiques à moitié configurées. Soit désactivez IPv6 au niveau OS/réseau intentionnellement (avec plan de déploiement), soit verrouillez‑le de manière cohérente.

Task 14: Validate with a real SSH connection attempt, then verify logs

cr0x@server:~$ sudo journalctl -u ssh --since '10 minutes ago' --no-pager | tail -n 8
Dec 28 09:31:44 server sshd[1890]: Connection from 198.51.100.25 port 55312 on 203.0.113.10 port 22 rdomain ""
Dec 28 09:31:45 server sshd[1890]: Accepted publickey for admin from 198.51.100.25 port 55312 ssh2: ED25519 SHA256:Zk1...
Dec 28 09:31:45 server sshd[1890]: pam_unix(sshd:session): session opened for user admin(uid=1000) by (uid=0)

Signification : La connexion a atteint sshd et s’est authentifiée. Vous êtes de nouveau opérationnel.

Décision : Ce n’est qu’à présent que vous devez supprimer les exceptions temporaires et finaliser la politique.

Task 15: If you must, do a controlled UFW disable/re-enable

cr0x@server:~$ sudo ufw disable
Firewall stopped and disabled on system startup

cr0x@server:~$ sudo ufw enable
Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup

Signification : C’est le « gros levier ». Il peut vous sortir d’affaire, mais aussi ouvrir l’hôte complètement pendant un bref instant, selon les autres couches.

Décision : Utilisez‑le seulement quand vous comprenez l’exposition et que vous avez des contrôles compensatoires (pare‑feu cloud, réseau privé, fenêtre de maintenance). Préférez les corrections ciblées des règles.

Task 16: Confirm persistence and systemd integration

cr0x@server:~$ systemctl is-enabled ufw
enabled

cr0x@server:~$ sudo ufw status
Status: active

Signification : UFW sera appliqué au démarrage et est actif maintenant.

Décision : S’il est désactivé, décidez si c’est une posture intentionnelle. « On l’a désactivé pour récupérer et on a oublié » n’est pas une stratégie, c’est un futur incident.

Trois mini-histoires d’entreprise du terrain

1) Incident causé par une mauvaise hypothèse : « Allow SSH » n’était pas ce qu’ils pensaient

Une entreprise de taille moyenne gérait une flotte de serveurs Ubuntu répartis entre sous‑réseaux publics et privés. L’équipe avait l’habitude : garder SSH ouvert seulement vers une plage VPN d’entreprise. Raisonnable. Un jour, lors d’une vague de mises à jour système, un ingénieur a décidé de « standardiser les règles de pare‑feu » et a déployé des changements UFW via l’automatisation.

Le changement semblait sûr dans la revue de code : il ajoutait ufw allow 22/tcp puis une règle deny‑all. L’hypothèse était que « deny‑all » n’affecterait que les ports non listés, et que SSH resterait ouvert. Ce qui a été manqué : un ancien rôle ajoutait aussi une règle deny 22/tcp sur des hôtes qui devaient être accessibles seulement via un bastion. Deux sources de vérité. Une amicale, une hostile.

Pendant le déploiement, les sessions SSH existantes sont restées actives à cause du suivi d’état, donc personne n’a remarqué. Puis un script de maintenance a fermé les sessions inactives. Soudain, les nouvelles sessions ont échoué sur une partie de la flotte. Le NOC a vu « SSH down » et a traité cela comme une panne réseau. Ce n’était pas le cas. C’était un logiciel fonctionnel appliquant une politique contradictoire.

La récupération a été lente parce que l’équipe a essayé de réparer depuis leurs laptops d’abord. Ils n’ont pas pu entrer. Finalement, ils ont utilisé les consoles du fournisseur cloud pour ajouter une règle allow depuis une IP de gestion, exactement comme décrit plus haut. La correction réelle était ennuyeuse : supprimer la règle deny dupliquée, ajouter des commentaires et faire qu’un seul module gère les règles SSH. Le postmortem a donné une leçon encore plus ennuyeuse : « les hypothèses ne sont pas des tests ».

2) Optimisation qui s’est retournée contre eux : réduire le jeu de règles sans comprendre l’évaluation

Une autre organisation avait une équipe sécurité qui n’aimait pas les « règles en désordre ». Ils ont demandé à la plateforme de réduire le nombre d’entrées de pare‑feu et de supprimer des autorisations IPv6 « redondantes ». L’équipe plateforme a obtempéré rapidement. Trop rapidement.

Ils ont enlevé des allow IPv6 explicites en partant de l’idée que « personne n’utilise IPv6 » pour réduire le bruit d’audit. Mais un sous‑ensemble d’ordinateurs portables d’entreprise préférait IPv6, et leur client VPN fuyait des routes IPv6 d’une manière qui faisait que les clients essayaient d’abord v6. Résultat : échecs SSH intermittents selon l’OS client, le réseau et l’ordre des réponses DNS. Les tickets étaient un chef‑d’œuvre de confusion.

Puis est venue l’« optimisation » : pour simplifier, quelqu’un a remplacé une règle allow‑from spécifique par un allow large et a compté sur le rate‑limiting SSH côté application. Cela a réduit le nombre de règles. Cela a aussi augmenté l’exposition et le volume de logs, et rendu les tentatives par force brute plus visibles en aval.

La correction a aussi été peu glamour : restaurer des règles IPv6 explicites, garder des allow‑lists serrées et utiliser le logging UFW en low/medium avec agrégation centrale des logs. L’équipe a appris que « moins de règles » n’est pas intrinsèquement mieux. Des règles correctes le sont.

3) Pratique ennuyeuse mais correcte qui a sauvé la mise : accès console et déploiements par étapes

Une société de services financiers avait une habitude que j’aimerais voir partout : chaque serveur de production disposait d’un accès out‑of‑band testé, et chaque changement de pare‑feu était réalisé en trois étapes. Étape une : ajouter la nouvelle règle allow. Étape deux : vérifier la connectivité depuis au moins deux réseaux. Étape trois : supprimer l’ancienne règle. La séquence paraît pédante. C’est aussi la raison pour laquelle ils dormaient bien.

Un soir, un ingénieur a durci les defaults d’UFW sur un groupe d’hôtes et a accidentellement retiré un sous‑réseau de gestion de la allow‑list. Ils l’ont remarqué en quelques minutes parce que leur test de fumée (une simple tentative de connexion SSH) a échoué en staging. Le même automatisme aurait ensuite touché la production.

Même si cela avait frappé la production, la procédure exigeait de garder la session console ouverte et d’avoir une commande de rollback prête. Ils n’ont pas eu à l’utiliser, car le déploiement par étapes a limité le rayon d’impact aux « quelques boîtes de test ». Pas de héros. Pas de pont de panique. Pas de directeur demandant pourquoi « un changement de pare‑feu peut couper le chiffre d’affaires ».

Ils ont corrigé la config, relancé le test et ont poursuivi. La partie la plus impressionnante était à quel point l’incident était peu intéressant. C’est l’objectif.

Checklists / plan pas-à-pas

Checklist de récupération (depuis la console, risque minimal)

Gardez la console ouverte. Ne la fermez pas tant que vous n’avez pas une nouvelle session SSH.
Confirmez sshd : systemctl status ssh.
Confirmez l’écoute : ss -ltnp | grep sshd.
Confirmez le réseau hôte : ip -br addr, ip route.
Vérifiez l’état UFW : ufw status verbose.
Ajoutez un allow restreint : ufw allow from <mgmt-ip> to any port 22 proto tcp.
Vérifiez l’ordre des règles : ufw status numbered.
Essayez SSH depuis l’IP de gestion.
Confirmez dans les logs : journalctl -u ssh et éventuellement les UFW BLOCK kernel logs.
Supprimez les règles deny accidentelles.
Décidez de la politique SSH finale : allow‑list vs anywhere ; inclure la décision IPv6.
Retirez les allowances TEMP et ajoutez des commentaires aux règles permanentes.

Checklist de stabilisation (après récupération)

Enregistrez la sortie UFW avant/après dans votre ticket.
Confirmez que les règles cloud firewall/security group correspondent à votre intention.
Confirmez le durcissement SSH : clés‑seulement, désactiver root login, méthodes d’auth sensées.
Assurez‑vous que vous pouvez joindre la machine via la console hors bande (et que les identifiants fonctionnent).
Planifiez un suivi pour resserrer les allow temporaires.

Vérité sèche et drôle #2 : Rien ne dit « entreprise » comme une règle de pare‑feu nommée TEMP datant d’il y a deux trimestres que tout le monde a peur de supprimer.

Erreurs courantes : symptômes → cause racine → correction

Symptôme : SSH met du temps à répondre ; UFW montre « active » mais « allow 22/tcp » existe.
Cause racine : Vous avez autorisé IPv4 mais vous vous connectez via IPv6 (ou vice versa), ou vous avez autorisé la mauvaise interface/plage d’IP.
Correction : Ajoutez des règles v6 explicites pour votre préfixe de gestion, ou confirmez que le client utilise IPv4 ; vérifiez avec ss et ufw status verbose.
Symptôme : SSH « No route to host » ou échec immédiat ; les logs UFW ne montrent rien.
Cause racine : Blocage en amont (security group cloud, NACL), problème de routage, ou mauvaise IP publique/DNS.
Correction : Vérifiez le pare‑feu du fournisseur et l’IP de l’instance ; contrôlez ip route et la console fournisseur. Ne continuez pas à modifier UFW quand les paquets n’arrivent jamais.
Symptôme : Les sessions SSH existantes fonctionnaient jusqu’à leur déconnexion ; les nouvelles échouent.
Cause racine : Le pare‑feu stateful a laissé passer les connexions établies ; les nouvelles inbound sont bloquées par la politique.
Correction : Ajoutez une règle allow pour les nouvelles connexions. Ne confondez pas « je suis toujours connecté » avec « tout est OK ».
Symptôme : UFW indique qu’une règle est présente, mais le comportement ne change pas.
Cause racine : Un autre gestionnaire de pare‑feu a écrasé les règles, ou UFW ne s’est pas appliqué proprement, ou vous déboguez la mauvaise machine/namespace.
Correction : Inspectez ufw show raw, vérifiez d’autres services (containers, orchestration) et confirmez que vous êtes sur la bonne machine (hostnamectl).
Symptôme : SSH atteint l’hôte mais l’auth échoue après des changements UFW.
Cause racine : Changements concomitants de configuration sshd, permissions de clés, ou problèmes PAM ; UFW est blâmé parce que c’était le dernier changement.
Correction : Consultez journalctl -u ssh, validez /etc/ssh/sshd_config, et testez localement avec ssh localhost.
Symptôme : Vous avez autorisé le port 22, mais SSH est sur 2222 (ou inversement).
Cause racine : Décalage entre la configuration sshd et les règles du pare‑feu ; parfois causé par des guides de durcissement.
Correction : Confirmez le port d’écoute avec ss -ltnp ; mettez à jour UFW en conséquence : ufw allow 2222/tcp.
Symptôme : Vous êtes certain d’avoir autorisé l’IP du bureau, mais vous ne pouvez toujours pas vous connecter.
Cause racine : Votre IP source a changé (fournisseur domestique, hotspot mobile, egress VPN).
Correction : Confirmez votre IP egress actuelle depuis un service connu ou un outil d’entreprise ; puis autorisez temporairement cette IP. Préférez VPN/bastion pour un egress stable.
Symptôme : UFW enable avertit d’une possible perturbation de SSH, puis c’est le cas.
Cause racine : Vous avez activé UFW avant d’ajouter la règle allow, ou le deny incoming par défaut s’est déclenché.
Correction : Depuis la console, ajoutez d’abord les règles allow ; ensuite activez. Pour des changements à distance, planifiez une fenêtre de maintenance ou utilisez un mécanisme de rollback programmé.

Prévenir le prochain verrouillage (sans se la jouer)

Une fois que vous avez récupéré l’accès, prenez cinq minutes pour réduire la probabilité d’une récidive. L’objectif n’est pas un spectacle de sécurité maximal ; c’est un accès contrôlé qui ne casse pas lors du travail courant.

1) Rendre l’accès SSH explicite et restreint

Choisissez un de ces modèles :

Modèle bastion : Seuls les bastions acceptent SSH depuis Internet ; tous les autres serveurs autorisent SSH seulement depuis le sous‑réseau du bastion.
Modèle VPN : Les serveurs autorisent SSH seulement depuis le pool d’adresses VPN.
Modèle sous‑réseau de gestion : Réseau admin dédié (on‑premise ou cloud) a l’accès ; tout le reste non.

Ne mixez pas les modèles à la légère. Les modèles mixtes conduisent à des règles allow/deny contradictoires et à une session console tardive la nuit.

2) Traitez IPv6 comme réel

Si votre hôte a une adresse IPv6 globale, Internet peut l’atteindre en IPv6 à moins que des filtres en amont n’en décident autrement. Décidez délibérément :

Si vous utilisez IPv6, écrivez des règles v6 allow pour les mêmes sources qu’en IPv4.
Si vous n’utilisez pas IPv6, soit désactivez‑le intentionnellement (avec tests) soit gardez‑le en default‑deny et assurez‑vous que vos clients ne le préfèrent pas de manière inattendue.

3) Gardez les règles UFW lisibles

Utilisez des commentaires. Le vous du futur est un étranger qui ne mérite pas de souffrir.

cr0x@server:~$ sudo ufw status numbered
Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     ALLOW IN    198.51.100.0/24             # SSH from mgmt subnet
[ 2] 80/tcp                     ALLOW IN    Anywhere                    # HTTP
[ 3] 443/tcp                    ALLOW IN    Anywhere                    # HTTPS

Décision : Si vos règles ne racontent pas d’histoire, réécrivez‑les jusqu’à ce qu’elles le fassent.

4) Ajoutez une méthode de rollback pour les changements de pare‑feu à distance

Dans les environnements matures, les changements de pare‑feu sont appliqués avec un rollback automatique si les tests de connectivité échouent. Vous pouvez approcher cela sans outil sophistiqué en procédant par étapes et en vérifiant depuis une session séparée, ou en utilisant un ordonnanceur de tâches pour revenir en arrière si la commande n’est pas annulée. En production, investissez dans un vrai mécanisme de changement plutôt que de vous fier au courage.

FAQ

1) Dois‑je juste lancer `ufw reset` ?

Seulement si vous acceptez de perdre toute votre politique de pare‑feu et de la reconstruire. C’est un instrument brutal. Préférez supprimer ou remplacer la règle spécifique qui bloque SSH.

2) Pourquoi ma session SSH existante est‑elle restée active quand UFW a bloqué SSH ?

Filtrage stateful. Les connexions établies peuvent rester autorisées tandis que les nouvelles connexions entrantes sont refusées. C’est utile jusqu’à ce que vous vous déconnectiez et découvriez que vous ne pouvez pas revenir.

3) J’ai autorisé `22/tcp` mais je ne peux toujours pas me connecter. Quel est le coupable habituel ?

Mauvais IP source, mismatch IPv6, règles pare‑feu en amont du cloud, ou sshd qui n’écoute pas sur l’interface que vous utilisez. Validez dans cet ordre.

4) Comment savoir si les paquets atteignent le serveur du tout ?

Vérifiez les logs noyau pour les UFW BLOCK. Si vous voyez des blocs, les paquets arrivent et UFW les rejette. Si vous ne voyez rien, suspectez un filtrage ou un routage en amont avant UFW.

5) Est‑il sûr d’autoriser temporairement SSH depuis Anywhere ?

Parfois c’est la seule solution pratique, mais ce n’est pas « sûr ». Si vous le faites, compensez : authentification par clés uniquement, pas de login root, et retirez l’allow large immédiatement après la récupération.

6) Ubuntu 24.04 utilise‑t‑il nftables ou iptables avec UFW ?

UFW est une interface ; le mécanisme sous‑jacent peut varier. Ne présumez pas. Utilisez ufw show raw et les outils système pour comprendre ce qui est réellement appliqué.

7) Pourquoi UFW avertit‑il que l’activer peut perturber les connexions SSH ?

Parce que ça peut. Si le default incoming devient deny et que vous n’avez pas correctement autorisé SSH, UFW bloquera volontiers les nouvelles connexions et peut perturber les flux existants selon les changements de règles.

8) Quelle est la configuration permanente la plus sûre pour SSH sur des serveurs exposés à Internet ?

Un modèle bastion ou VPN avec plages d’adresses allow‑listées, authentification par clés seulement et logging serré. Si SSH doit être public, traitez‑le comme une API publique et surveillez‑le en conséquence.

9) J’ai corrigé IPv4 mais IPv6 échoue encore. Est‑ce un problème ?

Si vos utilisateurs ou automatisations préfèrent IPv6, oui. Beaucoup de clients essaieront IPv6 en premier. Autorisez‑le correctement ou désactivez IPv6 intentionnellement avec un plan testé.

Conclusion : étapes suivantes à faire réellement

Vous avez récupéré SSH correctement : depuis la console, avec des autorisations restreintes et des preuves dans les logs plutôt qu’avec des impressions. Maintenant terminez le travail.

Supprimez toutes les règles TEMP ajoutées pendant la récupération et remplacez‑les par votre politique voulue (VPN/bastion/sous‑réseau mgmt).
Faites d’IPv6 une décision délibérée — soit le supporter correctement, soit le verrouiller de façon cohérente.
Rédigez un runbook minimal pour votre équipe : l’ordre de diagnostic rapide, les commandes UFW exactes et où se trouve l’accès console.
Effectuez les changements de pare‑feu en étapes à l’avenir : add allow → vérifier depuis deux réseaux → supprimer les anciennes règles. L’ennuyeux fonctionne.