Debian 13 : port SSH modifié — corriger l’ordre pare-feu + sshd sans se verrouiller (cas #27)

Case file #27: what went wrong (and why it’s common)

Le schéma ressemble à ceci : quelqu’un change SSH du port 22 vers un autre numéro — disons 2222 — pour « la sécurité ».
Ils éditent /etc/ssh/sshd_config, rechargent le service, puis ferment le port 22 dans le pare-feu.
La tentative de connexion suivante échoue, et maintenant le seul chemin pour revenir est la console hors-bande, iLO/DRAC, console série cloud, ou un ticket vers quelqu’un qui y a accès.

Sur Debian 13, la surface de risque est légèrement plus large que sur les systèmes plus anciens parce que :
les répertoires d’include (sshd_config.d) sont courants, le comportement d’systemd a plus d’importance, et les pare-feu sont de plus en plus basés sur nftables même quand l’administrateur pense « iptables ».
Le mode d’échec humain est constant : vous faites deux changements (sshd + pare-feu) et vous ne testez aucun des deux dans le bon ordre.

La solution n’est pas « faites attention ». La solution est une procédure déterministe : exécutez temporairement un port parallèle, ouvrez le pare-feu en premier, vérifiez le socket d’écoute,
vérifiez que l’authentification fonctionne sur le nouveau port, puis retirez l’ancien port. De préférence en gardant une seconde session ouverte tout le temps.

Faits & contexte : pourquoi les ports SSH et les pare-feu nous piègent

• SSH n’a pas toujours dominé l’administration distante. Avant de devenir la norme, les connexions distantes étaient souvent Telnet ou rlogin — non chiffrées et tragiquement confiantes.
• Le port 22 est une convention, pas une destinée. Il est attribué par l’IANA pour SSH, mais sshd peut se lier à n’importe quel port TCP que vous lui indiquez.
• « Sécurité par changement de port » est surtout du bruit. Cela réduit les scans de fond, pas les attaques ciblées. Cela peut néanmoins valoir la peine pour la lisibilité des logs, mais ne le confondez pas avec le contrôle d’accès.
• OpenSSH a popularisé des valeurs raisonnables par défaut. OpenSSH est devenu l’implémentation SSH standard sur Linux/BSD, et la plupart des comportements « SSH » que les admins attendent sont en fait des comportements OpenSSH.
• Debian a évolué vers les snippets d’include. Le schéma Include /etc/ssh/sshd_config.d/*.conf facilite la gestion de configuration — et rend les bugs d’override plus subtils.
• nftables a remplacé iptables dans le chemin noyau. Même si vous exécutez des commandes iptables, l’ensemble de règles sous-jacent peut être nftables (ou vous pouvez modifier la mauvaise chose entièrement).
• systemd change la nature des échecs. Un reload peut réussir tandis qu’un restart ultérieur échoue si la config contient un problème latent ; systemd rend aussi « quelle unité est active ? » important.
• Les pare-feu cloud sont séparés des pare-feu hôtes. Vous pouvez ouvrir nftables parfaitement et être toujours bloqué par un security group ou un pare-feu fournisseur.

Une citation à garder en poche, parce qu’elle est ennuyeuse et correcte :
L’espoir n’est pas une stratégie.
— idée paraphrasée souvent attribuée aux opérateurs axés sur la fiabilité

Votre modèle mental : sshd, systemd, et « qui possède le port »

Changer le port SSH n’est pas un réglage unique. C’est une chaîne :
client → chemin réseau → pare-feu cloud → pare-feu hôte → écoute sshd → authentification.
Si un maillon casse, l’utilisateur voit « SSH est en panne ». Votre travail est d’identifier rapidement quel maillon a cassé, sans empirer la situation.

Empilement de la config sshd : l’ordre des fichiers compte

Debian utilise couramment /etc/ssh/sshd_config plus un ou plusieurs snippets sous /etc/ssh/sshd_config.d/.
La configuration effective est le résultat de la lecture du fichier principal puis de l’application des includes dans l’ordre lexical.
Cela signifie que 00-foo.conf peut être remplacé par 99-bar.conf.
« J’ai changé Port dans sshd_config » ne veut rien dire si un include ultérieur le remet à sa valeur précédente.

Ports multiples : votre carte de sortie

OpenSSH supporte plusieurs directives Port. Si vous spécifiez deux ports, sshd écoute sur les deux.
C’est la manière la plus sûre de migrer : conservez 22 pour l’automatisation existante, ajoutez 2222 pour le nouvel accès, puis retirez 22 plus tard.

Ordre du pare-feu : ouvrir d’abord, fermer en dernier

Chaque système de pare-feu a une notion d’ordre d’évaluation des règles.
Mais la vérité opérationnelle est plus simple : si vous devez garder l’accès, vous ajoutez des règles allow pour le nouveau port
avant de supprimer les règles allow pour l’ancien port. À chaque fois. Aucune exception pour les « changements rapides ».

Blague n°1 : Changer les ports SSH sans une seconde session, c’est comme faire une mise à jour de firmware un vendredi — vous pouvez le faire, mais vous passez un casting pour les conséquences.

Mode opératoire de diagnostic rapide (premier/deuxième/troisième)

C’est le flux « j’ai besoin de réponses en cinq minutes ». Ne faites pas de freestyle. Suivez la chaîne.

Premier : est-ce que sshd écoute là où vous le pensez ?

• Vérifiez les sockets d’écoute (ss).
• Vérifiez la configuration effective de sshd (sshd -T).
• Vérifiez le statut du service et les logs récents (systemctl, journalctl).

Second : le pare-feu hôte le permet-il ?

• Identifiez le système de pare-feu réellement en charge : nftables, UFW, ou iptables hérité.
• Confirmez qu’une règle allow existe pour le nouveau port depuis vos réseaux sources.
• Confirmez qu’il n’y a pas une règle deny ultérieure qui la masque.

Troisième : quelque chose en dehors de l’hôte vous bloque-t-il ?

• Security group / pare-feu fournisseur cloud.
• ACL réseau, périmètre d’entreprise, politique VPN.
• Équilibreur de charge ou bastion qui attend un port différent.

Tâches pratiques : 14 commandes, sorties et décisions

Ce ne sont pas des « lancez des commandes pour vous amuser ». Chacune répond à une question précise et mène à une décision.
Exécutez-les depuis une session SSH existante si vous en avez encore une, et gardez cette session ouverte jusqu’à la fin.

Task 1 — Confirmer la version Debian et les hypothèses d’environnement

cr0x@server:~$ cat /etc/debian_version
13.0

Ce que ça signifie : Vous êtes sur Debian 13. Les valeurs par défaut et le packaging (y compris le comportement d’include de sshd) devraient correspondre aux attentes actuelles.
Décision : Procédez en supposant OpenSSH + systemd par défaut ; vérifiez quand même les includes.

Task 2 — Vérifier si sshd tourne et comment systemd le voit

cr0x@server:~$ systemctl status ssh
● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; enabled; preset: enabled)
     Active: active (running) since Mon 2025-12-30 08:41:12 UTC; 2h 11min ago
       Docs: man:sshd(8)
             man:sshd_config(5)
   Main PID: 914 (sshd)
      Tasks: 1 (limit: 19190)
     Memory: 7.2M
        CPU: 1.184s
     CGroup: /system.slice/ssh.service
             └─914 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups"

Ce que ça signifie : sshd est actif.
Décision : S’il n’est pas actif, ne touchez pas aux pare-feu pour l’instant — réparez d’abord sshd.

Task 3 — Voir sur quels ports sshd écoute réellement

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

Ce que ça signifie : Vous êtes dans l’état sûr : sshd écoute à la fois sur l’ancien et le nouveau port, IPv4 et IPv6.
Décision : Vous pouvez maintenant travailler sur les règles de pare-feu pour 2222 sans risquer l’accès.

Task 4 — Afficher la configuration effective de sshd (pas ce que vous pensez avoir défini)

cr0x@server:~$ sudo sshd -T | grep -E '^(port|listenaddress|passwordauthentication|pubkeyauthentication)\b'
port 22
port 2222
listenaddress 0.0.0.0
listenaddress ::
passwordauthentication no
pubkeyauthentication yes

Ce que ça signifie : La configuration effective inclut les deux ports ; l’authentification par mot de passe est désactivée (bien).
Décision : Si le port que vous voulez est absent ici, arrêtez-vous et corrigez l’ordre des includes/la syntaxe avant de toucher au pare-feu.

Task 5 — Inspecter l’ordre des includes et repérer les overrides

cr0x@server:~$ grep -nE '^(Include|Port)\b' /etc/ssh/sshd_config
12:Include /etc/ssh/sshd_config.d/*.conf
18:Port 22

cr0x@server:~$ ls -la /etc/ssh/sshd_config.d/
total 16
drwxr-xr-x 2 root root 4096 Dec 30 08:40 .
drwxr-xr-x 4 root root 4096 Dec 30 08:10 ..
-rw-r--r-- 1 root root   26 Dec 30 08:40 10-ports.conf
-rw-r--r-- 1 root root  124 Dec 30 08:10 50-hardening.conf

cr0x@server:~$ cat /etc/ssh/sshd_config.d/10-ports.conf
Port 22
Port 2222

Ce que ça signifie : Le changement de port est dans un snippet. C’est maintenable et plus compatible avec la gestion de configuration.
Décision : Préférez un fichier snippet dédié pour les ports ; évitez d’éditer les defaults gérés par le fournisseur sauf si vous les contrôlez.

Task 6 — Valider la syntaxe de la config sshd avant reload/restart

cr0x@server:~$ sudo sshd -t

Ce que ça signifie : Pas de sortie signifie que la syntaxe est OK.
Décision : Si vous obtenez des erreurs, ne redémarrez pas. Corrigez la config jusqu’à ce que sshd -t soit propre.

Task 7 — Identifier l’outil de pare-feu en charge (ne devinez pas)

cr0x@server:~$ sudo systemctl is-active nftables
inactive

cr0x@server:~$ sudo systemctl is-active ufw
active

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

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    10.20.0.0/16

Ce que ça signifie : UFW applique la politique entrante ; le service nftables n’est pas actif séparément.
Décision : Gérez les changements de port SSH via UFW, pas via des commandes nft ad-hoc qui pourraient ne pas persister sous UFW.

Task 8 — Ajouter une règle allow pour le nouveau port, limitée à votre source

cr0x@server:~$ sudo ufw allow from 10.20.0.0/16 to any port 2222 proto tcp
Rule added

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

     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     ALLOW IN    10.20.0.0/16
[ 2] 2222/tcp                   ALLOW IN    10.20.0.0/16

Ce que ça signifie : Nouveau port autorisé depuis le même réseau que l’ancien.
Décision : N’autorisez pas 2222 depuis « Anywhere » à moins d’avoir une raison. Si vous le faites, activez le logging et un rate-limit au minimum.

Task 9 — Confirmer que le noyau voit l’autorisation (vue nft sous UFW)

cr0x@server:~$ sudo nft list ruleset | grep -nE 'tcp dport (22|2222)' | head
187: tcp dport 22 ct state new counter accept
190: tcp dport 2222 ct state new counter accept

Ce que ça signifie : Sous le capot, UFW a peuplé les règles nftables permettant les deux ports.
Décision : Si vous ne voyez pas 2222 ici, vos changements UFW ne se sont pas appliqués ou une autre couche de pare-feu prend le pas.

Task 10 — Tester le nouveau port depuis l’hôte (sanity check)

cr0x@server:~$ ssh -p 2222 -o BatchMode=yes -o ConnectTimeout=3 localhost 'echo ok'
ok

Ce que ça signifie : Le listener sshd sur 2222 accepte des connexions et votre authentification par clé fonctionne.
Décision : Si localhost échoue, l’accès externe échouera aussi. Corrigez sshd/auth avant de changer la périphérie.

Task 11 — Tester le nouveau port depuis une machine distante avant de fermer 22

cr0x@server:~$ sudo journalctl -u ssh -n 5 --no-pager
Dec 30 10:51:07 server sshd[3842]: Accepted publickey for cr0x from 10.20.14.9 port 51788 ssh2: ED25519 SHA256:3kz...
Dec 30 10:51:07 server sshd[3842]: pam_unix(sshd:session): session opened for user cr0x(uid=1000) by (uid=0)
Dec 30 10:51:10 server sshd[3842]: pam_unix(sshd:session): session closed for user cr0x

Ce que ça signifie : Quelqu’un (espérons que c’est vous) s’est connecté avec succès récemment. Les logs confirment l’acceptation, l’IP source et la méthode d’auth.
Décision : Ne fermez pas le port 22 tant que vous n’avez pas vu une connexion réussie sur 2222 depuis le réseau que vous utilisez réellement.

Task 12 — Vérifier les hypothèses sur le pare-feu cloud/fournisseur (Linux ne peut pas corriger ça)

cr0x@server:~$ sudo ss -ltnp | grep ':2222 '
LISTEN 0      128          0.0.0.0:2222      0.0.0.0:*    users:(("sshd",pid=914,fd=4))

Ce que ça signifie : L’hôte écoute. Si les connexions distantes timeout encore, suspectez les contrôles en amont.
Décision : Vérifiez le pare-feu fournisseur/security group/NACL équivalent et ouvrez TCP/2222 depuis vos plages sources. Ne supposez pas que le pare-feu hôte est la seule porte.

Task 13 — Recharger sshd en toute sécurité ; évitez restart quand ce n’est pas nécessaire

cr0x@server:~$ sudo systemctl reload ssh

cr0x@server:~$ systemctl show -p ActiveState,SubState,ExecMainStatus ssh
ActiveState=active
SubState=running
ExecMainStatus=0

Ce que ça signifie : Le reload n’a pas tué votre listener.
Décision : Préférez reload pour les changements de config. Restart est plus bruyant et plus sujet aux échecs si quelque chose ne va pas.

Task 14 — Retirer le port 22 seulement après réussite vérifiée, puis confirmer les sockets d’écoute

cr0x@server:~$ sudo sed -i 's/^Port 22$/# Port 22/' /etc/ssh/sshd_config.d/10-ports.conf

cr0x@server:~$ sudo sshd -t

cr0x@server:~$ sudo systemctl reload ssh

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

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

Ce que ça signifie : sshd ne lie plus 22, et le pare-feu ne le permet plus.
Décision : Ne faites cela qu’après avoir prouvé que 2222 fonctionne depuis l’extérieur. Gardez quand même votre session actuelle ouverte, parce que vous aimez dormir.

Check-lists / plan pas à pas : changer le port sans panique

Checklist pré-vol (avant de toucher quoi que ce soit)

• Ayez deux chemins d’accès : deux sessions SSH, ou SSH + accès console (console série cloud, IPMI, etc.). Si vous n’avez qu’un seul chemin, arrêtez-vous.
• Connaissez vos couches de pare-feu : pare-feu fournisseur + pare-feu hôte + ACL réseau d’entreprise. Notez où il faut ouvrir le port.
• Confirmez le mode d’auth : si vous désactivez l’auth par mot de passe, vérifiez que l’auth par clé fonctionne maintenant. Ne combinez pas « changement de port » avec « durcissement de l’auth » en une seule fois.
• Décidez de la portée : « allow depuis le subnet VPN seulement » vaut mieux que « allow depuis n’importe où » sauf si vous construisez un bastion public volontairement.
• Choisissez un port avec intention : évitez 2222 parce que tout le monde l’utilise, sauf si vous aimez les logs bruyants. Choisissez un port qui correspond à votre modèle d’opération.

Plan d’exécution (l’ordre qui évite le verrouillage)

1. Ajoutez le nouveau port dans sshd comme écoute supplémentaire. Ne supprimez pas 22 pour l’instant.
2. Validez la config : sshd -t et sshd -T | grep ^port.
3. Rechargez sshd (pas restart) et vérifiez que ss montre les deux ports à l’écoute.
4. Ouvrez le nouveau port dans le pare-feu hôte. Vérifiez les règles au niveau noyau (nft/iptables) pour éviter les situations « UFW dit oui mais le noyau dit non ».
5. Ouvrez le nouveau port dans les pare-feu en amont (security groups cloud, pare-feu fournisseur, ACL d’entreprise) avant de tester à distance.
6. Testez depuis le réseau que vous utilisez réellement. Confirmez que les logs montrent une connexion acceptée sur le nouveau port.
7. Mettez à jour l’automatisation et les outils : inventaire Ansible, configs de bastion, contrôles de monitoring, jump hosts, et tout runbook humain.
8. Ce n’est qu’ensuite que vous retirez le port 22 de sshd et du pare-feu, dans cet ordre : sshd cesse d’écouter, puis le pare-feu cesse d’autoriser.
9. Vérification post-changement : connexion distante sur le nouveau port, confirmer que 22 est fermé (connection refused ou filtré), et surveiller les logs pour les échecs.

Plan de rollback (vous en aurez besoin)

• Si le nouveau port échoue mais que vous avez encore une session existante : ré-ajoutez Port 22, rechargez sshd, ré-ajoutez la règle allow pour 22, et retestez.
• Si vous êtes verrouillé hors du système : utilisez l’accès console, restaurez le snippet sshd, rechargez, puis corrigez le pare-feu. Si vous n’avez pas d’accès console, félicitations — vous venez de découvrir pourquoi l’accès console est une exigence.

Blague n°2 : Les pare-feu, c’est comme la politique de bureau — tout le monde oublie qu’ils existent jusqu’à ce qu’ils vous empêchent de travailler.

Trois mini-histoires d’entreprise (comment les équipes se font vraiment avoir)

Incident : la mauvaise hypothèse (« on a ouvert le port »)

Une équipe plateforme a fait basculer SSH du 22 vers 22022 sur une flotte. Ils avaient une norme : modifier sshd, puis mettre à jour UFW.
Le changement semblait propre dans leur outil de configuration. La fenêtre de déploiement était calme. Puis le support a commencé à signaler qu’un sous-ensemble d’hôtes était inaccessible.

L’ingénieur d’astreinte a vérifié l’une des machines « mortes » via la console hors-bande et a trouvé sshd écoutant sur 22022 exactement comme prévu.
UFW montrait aussi une règle allow pour 22022. C’est le moment où la confiance de tout le monde a augmenté — et elle n’aurait pas dû.

Le maillon manquant était en amont : ces hôtes vivaient dans un projet cloud différent avec un baseline de pare-feu fournisseur plus strict.
Le port 22 avait une règle allow explicite depuis le VPN de l’entreprise, tandis que tous les autres ports nécessitaient un processus d’exception séparé.
L’outil de configuration n’avait aucune visibilité sur cette couche, donc « on a ouvert le port » n’était vrai que depuis la VM.

La correction fut banale : coordonner les changements de pare-feu fournisseur et phaser le déploiement par segment réseau.
La leçon durable fut plus nette : traitez chaque changement de port comme une demande de changement inter-couches, pas comme un tweak local.

Optimisation qui a mal tourné : « restart est plus propre que reload »

Une autre équipe n’aimait pas la dérive de configuration. Leur guide de style interne imposait de redémarrer les services après tout changement de config.
Pour sshd, ils utilisaient systemctl restart ssh comme règle stricte. Ça paraissait discipliné.

Lors d’une migration de port, une faute de frappe anodine s’est glissée dans un snippet d’include — une option invalide placée sous le mauvais bloc Match.
L’erreur de syntaxe n’est devenue effective qu’au restart. Le reload aurait aussi échoué, mais le restart a causé un problème plus large : sshd s’est arrêté,
et comme systemd l’a considéré comme un démarrage infructueux, il y a eu un petit délai pendant qu’il réessayait. Assez pour que les sessions existantes restent actives, mais les nouvelles sessions furent bloquées.

Isolé, c’est un échec normal. En production, cela s’est produit en même temps qu’un incident séparé qui a forcé les opérateurs à ouvrir de nouvelles sessions rapidement.
Ils ont tapé dans le mur au pire moment possible : le restart a transformé un changement gérable en incident d’accès.

Par la suite, ils n’ont pas abandonné les restarts complètement. Ils sont devenus plus malins : valider les configs avec sshd -t, préférer reload quand possible,
et phaser les restarts seulement quand le risque est tolérable. « Plus propre » n’est pas un SLO.

Pratique ennuyeuse mais correcte : ports parallèles + pare-feu en phases ont sauvé la mise

Une entreprise liée aux finances avait un mandat de conformité : « déplacer SSH hors du 22 partout ». L’équipe sécurité voulait que ce soit fait rapidement.
Le responsable ops a refusé. Pas parce qu’il aimait le port 22, mais parce qu’il aimait davantage la disponibilité.

Ils ont mis en place un plan en deux phases. Phase 1 : ajouter un second port dans sshd sur tous les hôtes, l’ouvrir uniquement depuis les CIDR VPN,
et mettre à jour les bastions et l’automatisation pour préférer le nouveau port. Rien n’a été supprimé. Chaque machine a terminé la phase 1 avec deux portes fonctionnelles.

Ils ont ensuite attendu un cycle de changements complet. Pendant ce temps ils ont surveillé les logs pour tout client utilisant encore 22 — vieux scripts, jump boxes oubliés,
appliances fournisseurs, et le cron « temporaire » de quelqu’un qui avait survécu trois trimestres.

La phase 2 fut anticlimatique : retirer le port 22 dans sshd, puis supprimer l’allow pare-feu. Pas de verrouillage, pas de drame.
C’était presque décevant, ce qui est la bonne réponse émotionnelle à un changement d’infrastructure.

Erreurs courantes : symptôme → cause racine → fix

1) Symptom: “Connection refused” on the new port

Root cause: sshd ne figure pas à l’écoute sur ce port (la config ne s’est pas appliquée, override d’include, ou reload/restart a échoué).

Fix: Vérifiez ss -ltnp et sshd -T | grep ^port. Corrigez l’ordre des fichiers dans sshd_config.d. Exécutez sshd -t, puis systemctl reload ssh.

2) Symptom: “Connection timed out” on the new port

Root cause: drop par le pare-feu en amont (security group cloud, pare-feu hôte, ou ACL) ou problème de routage.

Fix: Confirmez que l’hôte écoute ; ensuite confirmez la règle du pare-feu hôte ; ensuite confirmez que le pare-feu fournisseur l’autorise. Les timeouts sont généralement des « drops », pas des « rejects ».

3) Symptom: UFW shows allow, but traffic still blocked

Root cause: vous n’utilisez pas réellement les règles UFW (un autre gestionnaire de pare-feu est actif), ou une règle ultérieure l’ombre.

Fix: Validez avec nft list ruleset et vérifiez l’état des services. Si nftables utilise un jeu de règles séparé, décidez d’un seul propriétaire et désactivez l’autre.

4) Symptom: sshd listens on IPv4 but not IPv6 (or vice versa)

Root cause: réglages AddressFamily ou ListenAddress, ou IPv6 système/réseau désactivé.

Fix: Vérifiez ss -ltnp pour [::]:PORT. Confirmez sshd -T | grep listenaddress. Ajustez la config de façon intentionnelle ; ne comptez pas sur les valeurs par défaut si ça vous importe.

5) Symptom: you can SSH from inside the host but not from outside

Root cause: pare-feu ou chemin réseau en amont bloque ; le test localhost contourne ces couches.

Fix: Testez depuis un pair sur le même subnet/VPN. Validez les règles du pare-feu fournisseur. Ne célébrez pas parce que localhost fonctionne.

6) Symptom: existing sessions stay alive, but you can’t open new ones after change

Root cause: restart de sshd a échoué ou les ports d’écoute ont changé de façon inattendue ; les sessions TCP établies survivent tant qu’elles ne sont pas fermées.

Fix: Vérifiez systemctl status ssh et journalctl -u ssh. Restaurez les ports d’écoute et rechargez. Gardez une session ouverte jusqu’à validation des nouvelles connexions.

7) Symptom: automation breaks (Ansible, scripts, monitoring)

Root cause: les clients hardcodent le port 22, ou comptent sur des suppositions dans ~/.ssh/config qui ne sont pas déployées partout.

Fix: Mettez à jour les inventaires et les configs SSH, ou utilisez des bastions basés sur DNS avec configuration centralisée. Faites un audit basé sur les logs avant de supprimer 22.

8) Symptom: port appears open, but authentication fails only on the new port

Root cause: les blocs Match s’appliquent différemment (par LocalPort, Address, ou User), ou une règle PAM/AllowUsers ne correspond pas.

Fix: Passez en revue la sortie de sshd -T et la logique Match. Vérifiez les logs pour les raisons de rejet d’auth ; corrigez les blocs Match pour que les deux ports partagent la politique voulue.

FAQ

1) Le changement de port SSH améliore-t-il réellement la sécurité ?

Il réduit le bruit opportuniste (les scans de commodité frappant le 22), ce qui peut améliorer le rapport signal/bruit des logs.
Cela ne remplace pas les contrôles réels : authentification par clés, désactivation des mots de passe quand c’est possible, MFA sur les bastions, et allowlists d’IP strictes.

2) Dois-je faire tourner SSH sur deux ports en permanence ?

Temporairement, oui — pendant la migration, c’est l’approche la plus sûre. En permanence, généralement non : vous augmentez la surface exposée sans gain opérationnel.
Gardez deux ports seulement si vous avez une raison claire (chemin bastion séparé vs chemin interne) et que vous le documentez.

3) Où placer la directive Port sur Debian 13 ?

Mettez-la dans un snippet dédié comme /etc/ssh/sshd_config.d/10-ports.conf.
C’est plus facile à gérer, plus simple à auditer, et moins susceptible d’être écrasé par des mises à jour de paquet ou d’autres outils.

4) Quelle est la différence entre « connection refused » et « timed out » ?

Refused signifie généralement qu’un composant a rejeté activement la connexion — rien n’écoute, ou un pare-feu rejette.
Timed out signifie généralement que les paquets sont perdus — souvent un pare-feu en amont ou un problème de routage.
Diagnosez-les différemment.

5) Reload ou restart sshd ?

Préférez le reload pour les changements de configuration. C’est moins disruptif. Validez quand même avec sshd -t d’abord.
Restart est pour quand c’est nécessaire, pas par réflexe.

6) Comment confirmer quel port sshd utilise réellement ?

Utilisez ss -ltnp pour voir les sockets d’écoute en live et sshd -T pour voir la configuration effective.
Ne faites pas confiance à « j’ai édité un fichier ». Faites confiance à ce que le processus fait.

7) J’ai ouvert le port sur le pare-feu de la VM. Pourquoi je ne peux pas me connecter ?

Parce que votre VM n’est pas le seul pare-feu. Les security groups cloud/pare-feu fournisseur et les ACL d’entreprise peuvent vous bloquer.
Si l’hôte écoute et que le pare-feu hôte l’autorise, suspectez les couches en amont ensuite.

8) Quel numéro de port devrais-je choisir ?

Choisissez quelque chose qui ne rentre pas en collision avec des services locaux et qui soit facile à standardiser pour votre équipe.
Évitez les « alternatifs populaires » si vous voulez réduire le bruit. Mais ne choisissez pas quelque chose d’extrême que personne ne retiendra.
La standardisation prime sur la créativité.

9) Puis-je changer le port SSH sans aucune interruption ?

Généralement oui : ajoutez un port supplémentaire, rechargez, ouvrez le pare-feu, testez, puis retirez l’ancien port plus tard.
Les sessions existantes restent ; les nouvelles sessions peuvent basculer progressivement.

Étapes suivantes pour garder votre job

Traitez les changements de port SSH comme tout autre changement en production : phasé, validé, réversible.
Le bon ordre n’est pas optionnel : sshd écoute sur les deux → pare-feu autorise les deux → test du nouveau port → mise à jour des clients → suppression de l’ancien port.
Tout le reste, c’est jouer à la roulette avec l’accès.

Étapes pratiques :

• Adoptez un fichier snippet standard pour les ports SSH sous /etc/ssh/sshd_config.d/.
• Codifiez la règle des deux sessions pour les changements d’accès distant.
• Rendez explicite la propriété des pare-feu (UFW vs nftables vs gestion de config) et éliminez le problème des « deux capitaines ».
• Auditez les logs pour l’utilisation résiduelle du port 22 avant de le fermer, en particulier pour l’automatisation et les outils fournisseurs.
• Documentez la voie de rollback et assurez-vous que l’accès console existe avant de commencer.