Changer le port SSH : utile ou non

Q: J'ai changé le port et je ne peux plus me connecter. Que faire ?

Revenez à la session restée ouverte, remettez Port 22 dans le fichier, puis appliquez comme à l'étape 4 : sudo sshd -t, puis sudo systemctl daemon-reload et sudo systemctl restart ssh.socket si systemctl is-active ssh.socket répond active, sinon sudo systemctl restart ssh. Contrôlez avec sudo ss -tlnp | grep ':22 '. Si aucune session n'est ouverte, vérifiez d'abord que le nouveau port est bien ouvert dans le pare-feu, puis passez par la console de votre hébergeur.

Q: Faut-il aussi interdire la connexion par mot de passe ?

Oui, c'est la mesure qui compte. Elle se règle par PasswordAuthentication no, une fois votre clé en place et testée : voir Ajouter une clé SSH sur un serveur Linux.

Ce guide s'appuie sur la page de manuel de sshd_config et sur le suivi du paquet openssh d'Ubuntu, qui documente la note ajoutée dans sshd_config pour la version à activation par socket, relus le 15 octobre 2026. Il vaut pour Ubuntu 26.04 et Debian 13.

Ce que le changement apporte, et ce qu'il n'apporte pas

Effet	Avec un port changé
Tentatives de robots dans les journaux	nettement moins nombreuses
Protection contre un attaquant qui vous vise	aucune : un balayage trouve le port
Protection contre le vol de mot de passe	aucune : seule la connexion par clé l'apporte
Contraintes	préciser le port dans chaque outil qui se connecte

Un serveur qui n'accepte que les clés ne craint pas les essais de mots de passe, quel que soit leur nombre : ils échouent tous. Le changement de port reste un confort, utile si les journaux sont trop chargés pour être lus.

Il a un coût : chaque client SSH, chaque outil de déploiement, chaque tunnel doit connaître le nouveau port. Un outil oublié échoue, parfois des semaines plus tard.

Avant de commencer

Gardez une session SSH ouverte pendant toute la manœuvre. Si la nouvelle configuration échoue, c'est elle qui vous permet de réparer.
Choisissez un port libre au-dessus de 1024, par exemple 2222, et vérifiez que rien n'écoute dessus : sudo ss -tlnp | grep 2222 ne doit rien renvoyer.

Changer le port, dans l'ordre

Ouvrez le nouveau port dans le pare-feu qui protège le serveur, en TCP, avant toute autre chose. Sinon, SSH écoutera sur un port que personne ne peut joindre.
Ajoutez le nouveau port à SSH sans retirer l'ancien. La page de manuel précise que l'option Port peut être répétée. Créez /etc/ssh/sshd_config.d/02-port.conf :

Port 22
Port 2222

Vérifiez la configuration : sudo sshd -t ne doit rien afficher.
Appliquez-la. Regardez d'abord si SSH est lancé par un socket de systemd : systemctl is-active ssh.socket. - Si la réponse est active, comme sur une installation récente d'Ubuntu, le port est tenu par le socket : la note d'Ubuntu demande sudo systemctl daemon-reload puis sudo systemctl restart ssh.socket. Redémarrer seulement le service laisse SSH sur l'ancien port. - Sinon, redémarrez le service : sudo systemctl restart ssh.
Vérifiez l'écoute : sudo ss -tlnp | grep -E ':22 |:2222 ' doit montrer les deux ports.
Testez depuis un second terminal, sans fermer le premier : ssh -p 2222 admin@adresse-du-serveur.
Retirez l'ancien port une fois le test réussi : supprimez la ligne Port 22 du fichier, puis refaites les étapes 3 à 6 en testant le nouveau port seul. Mettez ensuite fail2ban à jour comme expliqué ci-dessous : sa prison vise encore le port 22.

Mettre fail2ban à jour

La prison sshd de fail2ban bannit par défaut sur le port nommé ssh, c'est-à-dire 22, d'après le fichier jail.conf de fail2ban. Avec un autre port, le bannissement ne bloquerait plus rien. Créez /etc/fail2ban/jail.d/port-ssh.local :

[sshd]
port = 2222

Tant que les deux ports sont ouverts, indiquez-les tous les deux, séparés par une virgule, comme le fait jail.conf pour http,https : port = 22,2222. Ne gardez que 2222 une fois l'ancien port retiré. Rechargez fail2ban après chaque changement : sudo fail2ban-client reload. Le réglage de la prison est expliqué dans Fail2ban : installer et configurer sur Linux.

Se connecter ensuite

Sur votre ordinateur, notez le port dans ~/.ssh/config pour ne plus avoir à le taper :

Host mon-serveur
    HostName adresse-du-serveur
    User admin
    Port 2222

ssh mon-serveur suffit alors. Pensez aux autres outils : client SFTP, tunnel, sauvegarde distante, et workflow de déploiement, comme celui de GitLab CI, où le port s'ajoute à la commande ssh avec -p 2222.

Sur un VPS Hubspace

Le pare-feu réseau placé devant le serveur n'ouvre que les ports 22, 80 et 443. Ouvrez le nouveau port à l'étape 1 dans l'espace client, sur votre VPS, onglet « Firewalls » : la règle que vous créez s'ajoute aux nôtres, elle ne les remplace pas, et le port 22 reste donc ouvert dans ce pare-feu. La connexion se fait déjà par clé seulement, root est réservé à notre équipe pour dépanner, et fail2ban surveille SSH : le changement de port n'ajoute que de la tranquillité dans les journaux. Si vous vous coupez l'accès, la console et le mode de secours de l'espace client existent, et le support peut vous aider depuis votre espace client. Les autres mesures sont dans Sécuriser un VPS.

Questions fréquentes

Quel port choisir ?

Un port libre au-dessus de 1024, qui ne sert à aucun autre service du serveur. Évitez les ports déjà ouverts pour vos applications, comme 80 et 443.

J'ai changé le port et je ne peux plus me connecter. Que faire ?

Revenez à la session restée ouverte, remettez Port 22 dans le fichier, puis appliquez comme à l'étape 4 : sudo sshd -t, puis sudo systemctl daemon-reload et sudo systemctl restart ssh.socket si systemctl is-active ssh.socket répond active, sinon sudo systemctl restart ssh. Contrôlez avec sudo ss -tlnp | grep ':22 '. Si aucune session n'est ouverte, vérifiez d'abord que le nouveau port est bien ouvert dans le pare-feu, puis passez par la console de votre hébergeur.

Faut-il aussi interdire la connexion par mot de passe ?

Oui, c'est la mesure qui compte. Elle se règle par PasswordAuthentication no, une fois votre clé en place et testée : voir Ajouter une clé SSH sur un serveur Linux.