Changer le port SSH 22 : ce que ça règle et ce que non

Le résumé honnête

Déplacer SSH hors du 22 réduira votre volume de connexions échouées d'environ 90% du jour au lendemain. Ce n'est pas non plus un contrôle de sécurité, et le traiter comme tel est la façon dont des serveurs se font compromettre par des administrateurs persuadés d'avoir terminé.

Les deux affirmations sont vraies parce qu'elles répondent à des questions différentes. La baisse de volume est réelle, mesurable et utile. La protection est proche de zéro face à quiconque passe trente secondes à regarder.

Faut-il le faire ? Généralement oui — comme réduction de bruit, à côté d'une vraie défense, jamais à sa place.

Ce que ça arrête vraiment

L'immense majorité du trafic d'attaque SSH vient de scanners non ciblés qui font une seule chose : se connecter au port 22 sur de grandes plages d'adresses et essayer des identifiants sur tout ce qui répond. Ils ne balaient pas les ports : vérifier un port sur tout internet coûte des ordres de grandeur de moins que 65 535, et il y a bien assez de machines sur 22 pour les occuper.

Passez au 52200 et vous sortez entièrement de cette population. La courbe s'effondre, le journal d'authentification cesse de tourner toutes les quelques heures, et y retrouver un vrai événement redevient possible.

Ce dernier point est sous-estimé. Un journal lisible vaut de l'argent pendant un incident, et à trois mille échecs par jour vous n'en avez pas.

Ce que ça n'arrête pas

Quiconque balaie toute la plage de ports vous trouve en quelques minutes. SSH s'annonce en clair — la bannière de version est la première chose que le service envoie — donc un scanner qui parcourt tous les ports et lit les bannières étiquette correctement votre service du premier coup.

Shodan et Censys font exactement cela en continu et publient les résultats sous forme d'index consultable. Votre port SSH non standard s'y trouve, trouvable par n'importe qui, en quelques jours.

Donc face à un bot non ciblé, changer le port fonctionne. Face à quelqu'un qui vous a choisi, cela lui coûte quelques minutes. Et cela ne fait rien contre des mots de passe faibles, une clé fuitée, un sshd non corrigé ou une application vulnérable sur le même hôte.

Il y a aussi un inconvénient actif : les ports inhabituels cassent des choses. Les pare-feux d'entreprise qui autorisent le 22 sortant bloqueront le 52200 sortant, et vous l'apprendrez d'un collègue qui ne peut pas déployer.

Changer sans se bloquer dehors

Deux étapes manquent dans la plupart des guides et toutes deux vous bloqueront sur une distribution moderne : l'étiquetage de port SELinux dans la famille RHEL, et l'activation par socket systemd sur Debian et Ubuntu récents, où sshd n'écoute plus lui-même.

Gardez votre session actuelle ouverte tout du long, et suivez cet ordre :

NEWPORT=52200

# 1. Le pare-feu D'ABORD — avant que sshd ne bouge
sudo ufw allow ${NEWPORT}/tcp                                          # Debian/Ubuntu avec ufw
sudo firewall-cmd --permanent --add-port=${NEWPORT}/tcp && sudo firewall-cmd --reload   # famille RHEL

# 2. SELinux : étiqueter le port, sinon sshd refusera de s'y attacher (RHEL)
sudo semanage port -a -t ssh_port_t -p tcp ${NEWPORT} || \
  sudo semanage port -m -t ssh_port_t -p tcp ${NEWPORT}

# 3. Prévenir sshd. Garder 22 pour l'instant — deux ports, pour ne pas être coupé
printf 'Port 22\nPort %s\n' "$NEWPORT" | sudo tee /etc/ssh/sshd_config.d/20-port.conf
sudo sshd -t                            # contrôle de syntaxe avant tout rechargement

# 4. Activation par socket : sur Debian/Ubuntu récents sshd ne s'attache pas seul
systemctl is-enabled ssh.socket 2>/dev/null && \
  echo 'ssh.socket est actif — surchargez ListenStream là-bas, voir la note ci-dessous'

sudo systemctl reload ssh               # 'sshd' dans la famille RHEL

Terminer le déplacement

Vérifiez maintenant depuis un second terminal sur le nouveau port — ssh -p 52200 user@server — avant de toucher à autre chose. Seulement une fois que cela marche, retirez Port 22 de la configuration, rechargez à nouveau et fermez l'ancienne règle de pare-feu.

Puis mettez à jour tout ce qui stockait l'ancien port : entrées de ~/.ssh/config, scripts de déploiement, runners CI, inventaires Ansible, vérifications de supervision, tâches de sauvegarde et documentation de votre équipe. Un changement de port qui casse la sauvegarde nocturne est pire que pas de changement du tout.

Ne retirez pas le port 22 avant d'avoir confirmé que le nouveau fonctionne depuis l'extérieur de votre réseau. Dans le LAN tout marche de toute façon, et c'est exactement ainsi qu'on se persuade que tout va bien.

Avec quoi le combiner

Changer de port réduit le bruit. Quelque chose doit encore traiter les tentatives qui arrivent — et après un changement de port, celles qui arrivent viennent de quelqu'un qui vous cherchait précisément, c'est-à-dire celles qui vous importent.

SSH Protector détecte le vrai port SSH depuis la configuration effective de sshd au lieu de supposer 22, un serveur déjà déplacé est donc couvert sans rien configurer, et ses règles sont reconstruites si le port change encore.

Changez le port pour un journal lisible. Gardez une défense pour le trafic qui vous trouve quand même.