SSH et port 22 : se connecter à un serveur et le sécuriser

TL;DRLe port 22 est le port TCP du protocole SSH, qui sert à administrer un serveur à distance et à transférer des fichiers en SFTP. Pour le sécuriser, l'essentiel tient en trois gestes : authentification par clé ed25519, mots de passe et connexion root directe désactivés, accès filtré au pare-feu. fail2ban et le changement de port complètent le dispositif sans le remplacer.

📌 Le port 22, porte d'entrée de l'administration à distance#

Le port 22 est le port TCP attribué par l'IANA au protocole SSH (Secure Shell). SSH sert à ouvrir un terminal sur une machine distante, à transférer des fichiers et à faire passer d'autres flux dans un tunnel chiffré. Il remplace Telnet, rlogin et FTP, qui faisaient circuler les mots de passe en clair.

Le protocole SSH version 2 est décrit par une série de RFC publiées en 2006 : RFC 4251 pour l'architecture, RFC 4253 pour la couche transport. Concrètement, une connexion SSH se déroule en trois temps :

1. Négociation du chiffrement : le client et le serveur choisissent les algorithmes et établissent une clé de session.
2. Vérification du serveur : le client compare l'empreinte de la clé d'hôte avec celle qu'il a mémorisée dans ~/.ssh/known_hosts.
3. Authentification de l'utilisateur : par clé publique, par mot de passe ou par un autre mécanisme.

Sur un serveur Linux, l'implémentation quasi universelle est OpenSSH, développée par le projet OpenBSD. Le démon s'appelle sshd et sa configuration se trouve dans /etc/ssh/sshd_config.

Le port 22 n'a rien à voir avec les ports web. Le port 80 transporte le HTTP en clair (voir notre article sur le port 80), le port 443 transporte le HTTPS (voir le port 443). Le port 22, lui, donne accès au système lui-même. C'est pour cela qu'il est la cible favorite des robots qui balaient Internet.

🌐 Les ports à connaître sur un serveur web#

Pour la base de données, nous détaillons les bons réglages dans notre article sur le port 3306.

🌐 Vérifier que SSH écoute sur le serveur#

Commencez par regarder quels processus écoutent en TCP. La commande ss remplace l'ancien netstat :

sudo ss -tlnp | grep ssh

Les options signifient : -t TCP, -l sockets en écoute, -n numéros bruts, -p processus associé. Une ligne contenant 0.0.0.0:22 ou [::]:22 indique que SSH écoute sur toutes les interfaces. Une adresse précise, comme 10.0.0.5:22, indique une écoute limitée à une interface.

Vérifiez ensuite l'état du service. Sur Debian, il s'appelle ssh :

sudo systemctl status ssh

Depuis votre poste, testez l'accessibilité du port avec nc -vz adresse-du-serveur 22. Un message « succeeded » ou « open » confirme que le port répond. Un délai dépassé oriente plutôt vers un pare-feu ; un refus immédiat vers un service arrêté.

📌 Se connecter en SSH#

La syntaxe de base est la même sous Linux, macOS et Windows 10/11, qui intègre un client OpenSSH :

ssh utilisateur@adresse-du-serveur
ssh -p 2222 utilisateur@adresse-du-serveur   # si le port a été changé

À la première connexion, le client affiche l'empreinte de la clé du serveur et demande confirmation. Ne tapez pas « yes » machinalement : comparez cette empreinte avec celle fournie par votre hébergeur. Sur le serveur, elle s'obtient ainsi :

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Pour éviter de retaper les options, déclarez vos serveurs dans ~/.ssh/config :

Host prod
    HostName 203.0.113.10
    User deploy
    Port 22
    IdentityFile ~/.ssh/id_ed25519

Il suffit ensuite de taper ssh prod.

📌 Passer aux clés ed25519#

L'authentification par mot de passe est la principale faiblesse d'un port 22 exposé. Les robots testent en continu des couples identifiant / mot de passe. Une paire de clés supprime ce risque : la clé privée reste sur votre poste, seule la clé publique est copiée sur le serveur.

Générez une clé de type ed25519, courte, rapide et prise en charge par OpenSSH depuis la version 6.5 :

ssh-keygen -t ed25519 -C "prenom@poste-travail"

Acceptez l'emplacement par défaut (~/.ssh/id_ed25519) et choisissez une phrase de passe. Elle chiffre la clé privée sur le disque : si votre ordinateur est volé, la clé reste inutilisable. L'agent SSH (ssh-agent) évite de la retaper à chaque connexion.

Copiez ensuite la clé publique sur le serveur :

ssh-copy-id -i ~/.ssh/id_ed25519.pub utilisateur@adresse-du-serveur

La commande ajoute la clé au fichier ~/.ssh/authorized_keys de l'utilisateur distant. Testez une connexion : elle ne doit plus demander le mot de passe du compte, seulement la phrase de passe de la clé.

Gardez toujours une session SSH ouverte pendant que vous modifiez la configuration, et testez la nouvelle configuration depuis un second terminal. Si quelque chose casse, la session déjà ouverte vous permet de corriger. Sans elle, il ne reste que la console de secours de l'hébergeur.

📌 Durcir sshd_config#

Une fois les clés en place, désactivez les mots de passe. Sur Debian 12 et Ubuntu récents, le fichier principal inclut le dossier /etc/ssh/sshd_config.d/ dès ses premières lignes. Pour sshd, la première valeur lue l'emporte. Un fichier nommé 00-durcissement.conf passe donc avant un éventuel 50-cloud-init.conf qui réactiverait les mots de passe.

# /etc/ssh/sshd_config.d/00-durcissement.conf
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password
AllowUsers deploy admin
MaxAuthTries 3
LoginGraceTime 30
X11Forwarding no

Ce que fait chaque ligne :

• PasswordAuthentication no et KbdInteractiveAuthentication no : plus aucune authentification par mot de passe.
• PermitRootLogin prohibit-password : root ne peut se connecter qu'avec une clé. Mieux encore, PermitRootLogin no interdit totalement la connexion directe en root ; c'est la valeur recommandée par l'ANSSI. Vous passez alors par un compte nominatif et sudo.
• AllowUsers : liste blanche des comptes autorisés. Tout autre compte est refusé, même avec une clé valide. AllowGroups fait la même chose par groupe.
• MaxAuthTries et LoginGraceTime : limitent les essais et le temps laissé pour s'authentifier.

Vérifiez la syntaxe, contrôlez la valeur effective, puis rechargez :

sudo sshd -t
sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin|allowusers'
sudo systemctl reload ssh

sshd -t ne renvoie rien si la configuration est valide. sshd -T affiche la configuration réellement appliquée, après inclusions.

📌 Ce que recommande l'ANSSI#

L'ANSSI a publié une note technique, « Recommandations pour un usage sécurisé d'(Open)SSH » (DAT-NT-007, août 2015). Plusieurs points restent d'actualité :

• authentification par cryptographie asymétrique (clés) en priorité, et mot de passe à proscrire pour les comptes à privilèges élevés ;
• un compte par personne, et pas de connexion directe en root (PermitRootLogin no) ;
• restriction des accès aux seuls utilisateurs qui en ont besoin, avec AllowUsers ou AllowGroups ;
• écoute du serveur SSH sur une adresse d'administration uniquement, quand l'architecture le permet ;
• SCP ou SFTP à la place des protocoles historiques comme FTP ;
• clés DSA déconseillées, tailles minimales de 2 048 bits pour RSA et 256 bits pour ECDSA.

La note date de 2015 et ne cite pas ed25519, apparu peu avant dans OpenSSH. Une clé ed25519 relève de la même logique de cryptographie à courbe elliptique et est aujourd'hui le choix par défaut de nombreux administrateurs.

📌 Bloquer la force brute avec fail2ban#

Même avec les mots de passe désactivés, les robots continuent d'essayer et remplissent les journaux. fail2ban lit les journaux et bannit temporairement, via le pare-feu, les adresses qui échouent trop souvent.

sudo apt install fail2ban

Créez un fichier local plutôt que de modifier les fichiers du paquet :

# /etc/fail2ban/jail.local
[sshd]
enabled  = true
backend  = systemd
maxretry = 5
findtime = 10m
bantime  = 1h

Le paramètre backend = systemd est utile sur Debian 12, où les journaux d'authentification sont dans journald et non plus dans /var/log/auth.log. Redémarrez puis vérifiez :

sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

Ajoutez votre propre adresse IP fixe dans ignoreip si vous craignez de vous bannir vous-même.

📌 Filtrer le port 22 au pare-feu#

La meilleure protection reste de ne pas exposer le port 22 à tout Internet. Si vous disposez d'une IP fixe ou d'un VPN, n'autorisez que celle-ci.

📌 Avec ufw (Ubuntu, Debian)#

sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status numbered

Sans IP fixe, sudo ufw limit 22/tcp autorise SSH tout en refusant une adresse qui ouvre trop de connexions en peu de temps. Ajoutez toujours la règle SSH avantufw enable.

📌 Avec nftables#

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    ip saddr 203.0.113.10 tcp dport 22 accept
    tcp dport { 80, 443 } accept
    icmp type echo-request accept
    icmpv6 type { echo-request, nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept
  }
}

Chargez le fichier avec sudo nft -f /etc/nftables.conf depuis une session déjà ouverte : la règle established,related la maintient. Si votre hébergeur propose un pare-feu réseau en amont, il peut compléter ou remplacer ce filtrage local.

📌 Changer de port : intérêt réel et limites#

Déplacer SSH sur un autre port (par exemple 2222) est une mesure fréquente. L'ANSSI la mentionne pour un serveur exposé à un réseau non maîtrisé, en conseillant un port inférieur à 1024 pour limiter les usurpations par des services non privilégiés.

Ce que cela apporte : beaucoup moins de tentatives automatisées, donc des journaux plus lisibles et moins de charge pour fail2ban.

Ce que cela n'apporte pas : aucune protection contre un attaquant ciblé. Un scan de ports trouve le nouveau port en quelques secondes. Ce n'est pas un substitut aux clés ni au filtrage.

Si vous le faites, suivez cet ordre pour ne pas vous enfermer dehors :

1. autorisez le nouveau port au pare-feu (sudo ufw allow 2222/tcp) et chez l'hébergeur ;
2. ajoutez Port 2222 dans votre fichier de configuration sshd ;
3. testez avec sudo sshd -t, rechargez, puis connectez-vous avec ssh -p 2222 depuis un second terminal ;
4. retirez seulement ensuite l'autorisation du port 22.

Sur Ubuntu 22.10 et versions suivantes, SSH peut être lancé par activation de socket (ssh.socket). Après la modification, exécutez sudo systemctl daemon-reload puis sudo systemctl restart ssh.socket. Vérifiez enfin avec ss -tlnp que le nouveau port écoute.

📌 SFTP : transférer des fichiers par le port 22#

SFTP est un sous-système de SSH. Il utilise le même port, le même chiffrement et les mêmes clés. Il n'y a donc rien à ouvrir de plus, contrairement à FTP qui demande le port 21 et une plage de ports passifs.

sftp utilisateur@adresse-du-serveur
scp fichier.zip utilisateur@adresse-du-serveur:/var/www/

FileZilla, WinSCP ou Cyberduck se connectent en SFTP en choisissant ce protocole et le port 22. Pour un prestataire qui doit seulement déposer des fichiers, enfermez son compte dans un dossier, sans accès au shell :

Match Group sftponly
    ChrootDirectory /srv/sftp/%u
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no

Le dossier désigné par ChrootDirectory doit appartenir à root et ne pas être modifiable par un autre utilisateur ; créez un sous-dossier accessible en écriture pour les dépôts. Placez le bloc Match à la fin de la configuration : il s'applique à toutes les lignes qui le suivent.

📌 Récapitulatif des réglages#

Pensez aussi aux mises à jour : sudo apt update && sudo apt upgrade maintient OpenSSH à jour avec les correctifs de sécurité de votre distribution.

📌 Besoin d'aide ?#

Sécuriser SSH n'est qu'une partie de l'administration d'un serveur : mises à jour, sauvegardes, supervision et réaction aux incidents demandent un suivi régulier. Si vous préférez déléguer ce travail, notre article sur l'infogérance de serveur détaille ce qu'elle couvre et quand elle se justifie.

Websource héberge un grand nombre de sites et accompagne ses clients dès la commande, avec un accès SFTP par clé et des serveurs maintenus par notre équipe. La migration est offerte avec les offres Premium et Advanced, et réalisée sur devis avec l'offre Standard. Découvrez nos offres d'hébergement web.

❓ Questions fréquentes#

🌐 Le port 22 doit-il être ouvert sur mon serveur ?#

Il doit être joignable par les personnes qui administrent le serveur, pas forcément par tout Internet. L'idéal est de l'ouvrir uniquement à une IP fixe ou à un VPN. Sinon, gardez-le ouvert avec des clés obligatoires et fail2ban.

📌 Faut-il changer le port SSH par défaut ?#

C'est facultatif. Cela réduit fortement les tentatives automatisées et allège les journaux, mais un scan de ports retrouve le nouveau port. Ne le faites qu'en complément des clés et du filtrage, en ouvrant le nouveau port au pare-feu avant de fermer l'ancien.

📌 Quelle différence entre PermitRootLogin no et prohibit-password ?#

Avec no, root ne peut jamais se connecter directement en SSH : vous passez par un compte nominatif et sudo, comme le recommande l'ANSSI. Avec prohibit-password, root peut se connecter, mais seulement avec une clé. La première option est plus stricte et améliore la traçabilité.

📌 SFTP utilise-t-il un autre port que SSH ?#

Non. SFTP est un sous-système de SSH et passe par le même port, 22 par défaut. Il n'a rien à voir avec FTP ou FTPS, qui utilisent le port 21 et des ports passifs.

🌐 Je me suis bloqué hors de mon serveur, que faire ?#

Utilisez la console de secours ou le mode rescue proposés par votre hébergeur pour accéder au système sans SSH. Corrigez la configuration ou la règle de pare-feu, testez avec sshd -t puis rechargez. Pour éviter cela, gardez toujours une session ouverte pendant les modifications.

Article publié le 14/11/2026 sous la signature de Jonathan Gutierrez, rédigé à partir des sources citées ci-dessus, puis relu avant publication. Une information vous semble inexacte ou datée ? Signalez-le nous, nous corrigeons.