SSH · sécurité par l'obscurité

Changer le port SSH : ce que ça règle vraiment (et ce que ça ne règle pas)

2026-08-03 · HardStacked · 7 min de lecture

Tous les quelques mois, le même débat revient sur Reddit ou Hacker News : faut-il déplacer SSH hors du port 22 ? La moitié des réponses parlent de théâtre sécuritaire inutile. L'autre moitié jure par le port 2222. Les deux camps argumentent au ressenti. Nous, on va argumenter avec des captures de paquets et des journaux d'authentification, parce qu'on en a.

En juillet 2026, on a laissé une box Oracle x86 ordinaire en ligne, SSH sur le port par défaut, authentification par clé seulement (PasswordAuthentication no), et tcpdump à l'écoute en amont du pare-feu. Pas d'appât, pas de service simulé, juste une machine qui existe sur internet. Voici ce que les données disent du débat.

1. Ce que le port 22 reçoit vraiment

En 41 heures, la box a reçu 1234 tentatives de connexion SSH. Pas des scans de l'IP : de vraies tentatives d'authentification contre sshd.

Ces tentatives ont essayé 132 noms d'utilisateur distincts. Attention à la distinction : 1234 tentatives, ce n'est pas 132 attaquants qui essaient une fois chacun. Les mêmes noms reviennent encore et encore, depuis des endroits différents. Les 1234 tentatives venaient de 93 adresses sources réparties sur 61 réseaux distincts. Ce motif de dispersion, une ou deux adresses par réseau, c'est la signature d'un botnet, pas d'une personne. Personne n'est assis à un clavier en train de te viser. Une machine distribuée moud de l'espace d'adressage.

La liste des noms d'utilisateur te dit exactement ce que cette machine chasse. Quatre familles ressortent :

Les comptes serveur : admin, postgres, mysql, oracle. La chaîne DevOps : ansible, deploy, developer, les comptes qui détiennent les clés de tout le reste. Les identifiants d'usine des routeurs, équipements fibre et IoT : ubnt, AdminGPON, telecomadmin, huawei. Et les cartes de dev : pi, orangepi.

Un seul dictionnaire, pointé sur tout ce qui a une adresse IP. Ton VPS, le routeur du voisin et un Raspberry Pi abandonné derrière un port redirigé sont le même travail pour lui. Il ne te cherche pas, toi. Il cherche n'importe quoi.

Une chose que tu ne trouveras ni dans ces données, ni dans aucun journal sshd : les mots de passe essayés. sshd ne journalise jamais le mot de passe tenté, seulement le nom d'utilisateur et la source. Tout article qui publie un « top des mots de passe des attaquants » l'a obtenu avec un honeypot type Cowrie, qui simule l'authentification pour capturer les identifiants. De vrais journaux ne peuvent pas produire cette liste. Bon à savoir quand tu évalues tes sources.

2. Ce que déplacer le port fait vraiment

Ça nettoie tes journaux. C'est la réponse honnête et complète, et ce n'est pas rien.

Le trafic de botnet décrit plus haut, c'est du balayage de masse. Les scanners de masse optimisent la couverture au moindre coût, donc la plupart frappent le port 22 et passent au suivant. Mets sshd sur 22000 et la grande majorité de ce bruit n'atteint plus jamais ton démon. Ton journal passe de 1234 lignes de déchets en deux jours à une poignée.

Pourquoi c'est important, si ces déchets étaient inoffensifs de toute façon ? L'observabilité. Quand ton journal est à 99 % de la statique de botnet, un événement réel est invisible. Une tentative ciblée contre ton vrai nom d'utilisateur, à 3 h du matin, depuis une seule adresse, c'est une ligne noyée dans 1234. Sur un journal silencieux, cette même ligne saute aux yeux. Déplacer le port ne te rend pas plus dur à percer. Ça rend une vraie attaque visible quand elle arrive. C'est un gain de supervision, et il est réel.

Le coût aussi est réel. Un port non standard, c'est des -p dans chaque script, une entrée de config sur chaque client, une chose de plus à documenter, et un coéquipier barré dehors au pire moment parce que personne ne l'a averti. Sur une box perso, ça ne coûte presque rien. Sur une infra partagée, cette friction s'accumule.

3. Ce que ça ne fait pas

Ça ne te cache pas. nmap -p- parcourt les 65535 ports. Les scanners à l'échelle d'internet, ceux derrière Shodan et Censys, indexent les services sur ports non standards par routine, et sshd s'annonce lui-même avec sa bannière de version à quiconque se connecte. Contre le bruit de fond de masse, un port obscur filtre l'essentiel. Contre quelqu'un qui regarde réellement ton hôte, ça lui coûte un scan.

Le modèle de sécurité « ils ne me trouveront pas sur 2222 » s'effondre donc au premier balayage de plage complète. Si ton authentification ne survit pas au fait d'être trouvée, le numéro de port ne t'a jamais protégé. L'obscurité comme couche par-dessus de vrais contrôles : correct. L'obscurité comme contrôle : non.

4. Ton auditeur te paie 3 points pour te barrer dehors

Voici la partie que les débats de forum n'atteignent jamais. Ton auditeur de sécurité te pousse activement vers ce changement. Le test SSH-7408 de Lynis note la directive Port selon une logique simple : tout sauf 22 score mieux, pour un poids de 3 points. Sur notre box de mesure, en juillet 2026, après application de 32 correctifs, Port était la seule suggestion SSH qui restait dans tout le rapport. L'outil pointait littéralement vers un dernier geste, et ce geste était le changement de port.

Et mal exécuté, ce geste te coûte la machine. Notre propre correctif de pare-feu ouvre ufw allow 22/tcp et rien d'autre pour SSH. Change Port dans sshd_config sans avoir d'abord ouvert le nouveau port dans le pare-feu, sur une machine joignable uniquement par SSH, et tu viens de couper ta seule voie d'accès. Le coût n'est pas de redémarrer un service. Le coût est de réinstaller la machine. C'est exactement pour cette raison qu'on a refusé d'automatiser le changement de port dans notre propre produit.

Si tu le fais, fais-le dans cet ordre et aucun autre :

Jamais dans l'autre ordre. La règle générale dépasse SSH : on ne retire l'ancienne voie d'accès qu'après avoir prouvé la nouvelle, et sur une machine distante, une session déjà ouverte est le seul filet qui existe. Il n'y a pas de console vers laquelle marcher.

Prends une seconde pour savourer l'ironie. Le score d'audit récompense un changement capable de te barrer hors de ton propre serveur, et reste muet sur la seule précaution qui le rend survivable. Ça te dit ce qu'un chiffre d'audit mesure vraiment : la conformité, pas la prudence. La checklist sait que le port 22 est bruyant. Elle n'a aucune idée si tu as encore un chemin pour rentrer.

5. Ce qui marche vraiment, dans l'ordre

Voici la partie que nos données prouvent au lieu de la plaider.

L'authentification par clé seulement. Sur les 1234 tentatives contre notre box, le journal contient zéro ligne Failed password. Pas peu : zéro. Chaque tentative est morte en Invalid user ou en connexion fermée avant authentification. Avec PasswordAuthentication no, le botnet n'a jamais atteint l'étape où un mot de passe pourrait être essayé. Tout son dictionnaire, les 132 noms, a frappé un mur qui se fiche de ce qu'il devine. Voilà à quoi ça ressemble quand un contrôle élimine une classe d'attaque au lieu de la réduire.

PermitRootLogin no. Root est le seul nom d'utilisateur que l'attaquant n'a jamais à deviner, et le seul compte où une compromission est instantanément totale. Retire-le de la table.

La limitation du débit. fail2ban, des limites de connexion nftables, ou le MaxStartups de sshd. Une fois les clés obligatoires, le brute force est déjà mort ; la limitation sert surtout à empêcher le bruit de gaspiller tes ressources et ton attention.

Fais ces trois choses et le numéro de port redevient une question d'hygiène de journaux, exactement là où il doit être.

Une note pratique avant d'aller vérifier tes propres journaux : sur les images cloud minimales d'Ubuntu 24.04, /var/log/auth.log n'existe pas si rsyslog n'est pas installé. journald est primaire. Lis journalctl -u ssh, sinon tu vas fixer un fichier vide et conclure que personne ne cogne. Ils cognent.

6. La limite de notre mesure

Franchement : on a mesuré le port 22. On n'a pas fait tourner une box équivalente sur un port haut en parallèle, donc on n'a aucun chiffre comparatif sur la quantité de bruit qu'un changement de port élimine. Les faits mesurés : le volume et la nature du trafic sur le port par défaut, et le fait que l'auth par clé a tout arrêté avant l'étape du mot de passe. L'affirmation qu'un port haut coupe l'essentiel du bruit de masse, c'est un raisonnement sur le fonctionnement des scanners, et on te le présente comme un raisonnement, pas comme une mesure.

La version courte

Change le port si tu veux des journaux lisibles. C'est un gain légitime, mineur. Ne le classe juste pas sous « sécurité », et ne le laisse pas remplacer le correctif que nos 41 heures de données valident réellement : clés seulement, pas de login root, limiter le reste.