Port TCP 22 (SSH)

Le port TCP 22 est le port d'écoute par défaut du protocole SSH, et donc de tout ce qui passe par lui : shell distant, SFTP, SCP, rsync, git en mode SSH et tunnels. Attribué à SSH par l'IANA en 1995 et cité dans la RFC 4253, c'est aussi l'un des ports les plus scannés d'Internet, ce qui impose de le protéger dès qu'une machine est exposée.

Sommaire

Ce qui circule sur le port 22

Le port 22 a été attribué à SSH en 1995, quand Tatu Ylönen a publié la première version du protocole et demandé à l'IANA un numéro libre entre le 21 (FTP) et le 23 (Telnet), les deux services que SSH devait remplacer. Le choix n'était pas anodin : Telnet transmettait mots de passe et sessions en clair, SSH chiffre tout dès la négociation. La RFC 4253, qui décrit la couche transport de SSH-2, se contente d'indiquer que le serveur « écoute normalement sur le port 22 ».

Concrètement, une connexion sur ce port ouvre un canal chiffré dans lequel plusieurs services s'emboîtent. Le shell distant est le plus visible, mais le même port transporte SFTP (un sous-système de sshd, à ne pas confondre avec FTPS), SCP, rsync lancé avec -e ssh, les clones git de la forme git@github.com:org/repo.git, et les redirections de ports : ssh -L 8080:localhost:80 fait passer du HTTP distant dans la session, ssh -D 1080 transforme la connexion en proxy SOCKS.

Windows 10 (depuis la 1809) et Windows Server 2019 embarquent un serveur OpenSSH en fonctionnalité optionnelle. Il écoute lui aussi sur 22 et crée la règle de pare-feu OpenSSH-Server-In-TCP à l'installation.

Un détail qui surprend : l'IANA réserve aussi 22/udp et 22/sctp au nom de SSH, mais aucune implémentation courante ne les utilise. Si un scanner vous affiche udp/22 en open|filtered, ce n'est pas votre sshd qui répond. Mosh, qui se lance après une authentification SSH classique, bascule ensuite sur UDP, mais dans la plage 60000-61000.

Vérifier si le port 22 est ouvert

Côté serveur, ss -tlnp | grep ':22' liste le processus qui écoute et sur quelles adresses : 0.0.0.0 pour toutes les IPv4, [::] pour IPv6, 127.0.0.1 si sshd n'est joignable qu'en local. Côté client, nc -zv serveur 22 ou nmap -p 22 serveur donnent l'état vu du réseau, ce qui n'est pas la même chose. Un sshd qui écoute derrière un pare-feu en DROP restera invisible.

Le test le plus parlant reste la connexion brute. nc serveur 22 ou telnet serveur 22 affiche la chaîne d'identification que sshd envoie avant tout chiffrement, par exemple SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13. Cette bannière est publique par construction du protocole. Shodan et Censys l'indexent, ce qui permet à n'importe qui de lister les serveurs qui tournent encore une version vulnérable.

Résultat du test	État du port	Cause habituelle
Bannière SSH-2.0-…	Ouvert, sshd répond	Fonctionnement normal
Connection refused	Fermé (le serveur renvoie un RST)	sshd arrêté, ou configuré sur un autre port
Délai d'attente dépassé	Filtré	Pare-feu en DROP, security group cloud, NAT sans redirection
kex_exchange_identification: Connection closed by remote host	Ouvert, mais sshd coupe avant la négociation	MaxStartups atteint, pénalité PerSourcePenalties, ou un service autre que SSH derrière le port

Changer le port 22 : intérêt réel et pièges

Déplacer sshd sur un autre port ne protège contre rien de sérieux : nmap -sV identifie SSH sur n'importe quel numéro, et les scanners de masse testent aussi 2222, 22222 ou 2200. Ce que ça change, c'est le bruit. Sur une machine exposée, les tentatives automatisées se comptent en centaines ou en milliers par jour sur le port 22 et tombent à presque rien sur un port non standard. Les journaux redeviennent lisibles.

La procédure classique : modifier la directive Port dans /etc/ssh/sshd_config, ouvrir le nouveau port dans le pare-feu avant de recharger sshd, puis tester depuis une seconde session sans fermer la première. Sur RHEL, Rocky ou Alma, SELinux bloque l'écoute tant que le port n'est pas déclaré : semanage port -a -t ssh_port_t -p tcp 2222.

Le piège le plus fréquent concerne Ubuntu. Depuis la version 22.10, sshd est lancé par activation de socket systemd. Selon la version, la directive Port de sshd_config est ignorée, ou n'est prise en compte qu'après systemctl daemon-reload et un redémarrage de ssh.socket. Dans les deux cas, un simple reload de ssh.service laisse le démon sur 22, sans message d'erreur. Vérifiez avec systemctl status ssh.socket et, au besoin, surchargez le socket avec systemctl edit ssh.socket : une ligne ListenStream= vide pour effacer la valeur héritée, puis ListenStream=2222.

Côté client, précisez le port avec ssh -p 2222 utilisateur@serveur, ou fixez-le dans ~/.ssh/config avec une entrée Host. Attention à scp et sftp, qui utilisent -P majuscule pour la même option.

Ce qui arrive à un port 22 exposé, et comment le durcir

Le port 22 figure, avec 23, 80, 443, 445 et 3389, parmi les ports les plus sollicités par les scans automatisés. Une machine fraîchement créée chez un hébergeur reçoit en général ses premières tentatives de connexion en quelques minutes, sans qu'aucun nom de domaine ne pointe vers elle. Les attaques visent d'abord les mots de passe faibles sur root, admin, ubuntu ou pi, puis les versions vulnérables de sshd. En juillet 2024, la faille CVE-2024-6387 (regreSSHion) a rappelé ce que coûte un port 22 ouvert à tous : exécution de code à distance en tant que root, sans authentification, sur OpenSSH 8.5p1 à 9.7p1 sous Linux avec glibc.

L'assistant de lancement EC2 chez AWS propose encore par défaut une règle entrante sur le port 22 depuis 0.0.0.0/0, avec un avertissement que beaucoup ignorent. Restreindre la source à vos adresses, ou passer par un bastion ou un VPN, règle la plus grande partie du problème avant toute configuration de sshd.

Sur le serveur lui-même, le levier principal est l'authentification par clé : ssh-keygen -t ed25519 côté client, ssh-copy-id pour déposer la clé publique, puis PasswordAuthentication no. À partir de là, le brute force ne sert plus à rien, quelle que soit sa vitesse. Fail2ban reste utile contre le bruit (valeurs par défaut : 5 échecs en 10 minutes, bannissement de 10 minutes), et OpenSSH 9.8 a ajouté PerSourcePenalties, activé d'origine, qui pénalise les adresses qui enchaînent les échecs d'authentification.

Directive sshd_config	Valeur par défaut OpenSSH	Valeur recommandée
PasswordAuthentication	yes	no (clés uniquement)
PermitRootLogin	prohibit-password	no
MaxAuthTries	6	3
LoginGraceTime	120 secondes	30
AllowUsers	non défini (tous les comptes)	liste explicite des comptes autorisés
ListenAddress	0.0.0.0 et ::	l'adresse interne seule si un bastion existe

Ports voisins et confusions courantes

SFTP passe par le port 22, pas par le 21. Le nom prête à confusion avec FTPS, qui est du FTP classique enveloppé dans TLS et qui utilise le port 21 en mode explicite ou le 990 en mode implicite. Un client comme FileZilla propose les deux ; si le serveur n'écoute que sur 22, seul le mode SFTP fonctionnera.

Le port 23 est celui de Telnet, dont SSH a pris la place. Un port 23 encore ouvert sur un équipement réseau ou un objet connecté est un signal d'alerte en soi : le botnet Mirai s'est construit sur des identifiants Telnet par défaut. Le port 3389, celui du bureau à distance Windows (RDP), joue le même rôle d'accès administrateur que le 22 et attire les mêmes attaques.

SSH n'est pas lié au port 22 par le protocole. Dans les réseaux d'entreprise qui ne laissent sortir que 80 et 443, il est courant de faire écouter sshd sur 443, ou d'y placer sslh pour partager le port avec un serveur web. GitHub applique la même idée : ssh.github.com accepte les connexions SSH sur 443 pour les clients bloqués sur 22.

Testez vos connaissances

Quiz rapide Question 1 sur 3

Quel protocole l'IANA a-t-elle attribué au port TCP 22 ?

Questions fréquentes

Le port 22 est-il TCP ou UDP ?

TCP. SSH a besoin d'un transport fiable et ordonné pour sa négociation de clés et son multiplexage de canaux. L'IANA réserve aussi 22/udp et 22/sctp au nom de SSH, mais aucun serveur courant n'y écoute. Une règle de pare-feu n'a donc besoin d'autoriser que 22/tcp.

Faut-il fermer le port 22 ?

Sur une machine qui n'a pas besoin d'administration à distance, oui, ou au minimum le restreindre à des adresses sources connues. Sur un serveur administré à distance, la vraie question est : depuis où ? Un port 22 joignable uniquement depuis un VPN ou un bastion, avec authentification par clé, est un choix défendable. Un port 22 ouvert à tout Internet avec mot de passe autorisé ne l'est pas.

J’ai changé Port dans sshd_config mais sshd écoute toujours sur 22, pourquoi ?

Sur Ubuntu 22.10 et suivants, sshd est démarré par activation de socket systemd et la directive Port n'est pas lue par ssh.service. Vérifiez avec systemctl status ssh.socket, puis surchargez le socket (ListenStream=) ou désactivez-le au profit de ssh.service. Sur les distributions avec SELinux, le rechargement échoue tant que le port n'est pas déclaré avec semanage.

Comment voir qui tente de se connecter sur mon port 22 ?

journalctl -u ssh (Debian, Ubuntu) ou journalctl -u sshd (RHEL et dérivés), sinon /var/log/auth.log ou /var/log/secure. Les lignes « Failed password for invalid user … from … » montrent les tentatives, et lastb liste les échecs de connexion. Un serveur exposé sans filtrage en accumule souvent plusieurs centaines à plusieurs milliers par jour.

SFTP utilise-t-il le port 22 ou le 21 ?

Le 22. SFTP est un sous-système de SSH, activé dans sshd_config par la ligne Subsystem sftp. Le port 21 correspond à FTP et à FTPS en mode explicite, le 990 à FTPS implicite. Si votre client réclame le port 21 pour un serveur qui n'a que SSH, c'est le mauvais protocole qui est sélectionné, pas le mauvais port.