Port TCP du SFTP : le 22, et les pièges du 21, du 990 et du 115

Port 22 : ce qui se passe réellement à la connexion

Quand vous tapez sftp utilisateur@serveur, le client ouvre une connexion TCP sur le port 22 de la machine distante, la même que ssh. L’IANA a enregistré 22/tcp au nom de SSH, pas de SFTP : le transfert de fichiers n’a jamais reçu de numéro de port propre, parce qu’il vit à l’intérieur d’une session SSH existante.

Une fois la connexion TCP établie, les deux parties échangent leur bannière de version (le serveur annonce quelque chose comme SSH-2.0-OpenSSH_9.6p1), négocient les clés (RFC 4253), authentifient l’utilisateur (RFC 4252), puis le client ouvre un canal de session et envoie une requête « subsystem » portant le nom sftp, mécanisme décrit au paragraphe 6.5 du RFC 4254. Le serveur lance alors son binaire sftp-server, et toutes les opérations de fichiers circulent dans ce canal chiffré.

Le protocole de fichiers lui-même n’a jamais atteint le statut de RFC : il est resté à l’état de draft IETF (draft-ietf-secsh-filexfer). OpenSSH en implémente la version 3, complétée par des extensions maison comme posix-rename@openssh.com ou statvfs@openssh.com, ce qui explique pourquoi certains clients graphiques affichent « SFTP version 3 » sur un serveur pourtant récent.

Conséquence pratique : si SSH répond, SFTP répond. Sauf si l’administrateur a commenté la ligne Subsystem dans /etc/ssh/sshd_config, auquel cas le port 22 accepte la connexion, ssh fonctionne, et sftp échoue avec le message « Remote: subsystem request failed on channel 0 ». Le port n’y est pour rien.

• Ouverture TCP sur 22, échange des bannières de version
• Négociation de clés et vérification de la clé d’hôte
• Authentification par clé publique ou mot de passe
• Ouverture d’un canal et requête subsystem « sftp »
• Transfert des fichiers dans ce canal, sans nouvelle connexion TCP

SFTP, FTPS, FTP : trois protocoles, des ports différents

La confusion vient du nom. SFTP ne veut pas dire « FTP sécurisé » : il ne partage aucune ligne de code ni aucune commande avec FTP. FTPS, lui, est bien du FTP classique enveloppé dans du TLS, avec toute la mécanique de canal de données séparé qui va avec.

Un troisième piège traîne dans les registres. Le port 115/tcp est enregistré à l’IANA sous le libellé sftp, pour Simple File Transfer Protocol (RFC 913, 1984), un protocole sans rapport et abandonné depuis. Les assistants de configuration de pare-feu et certains scanners reprennent ce libellé tel quel, ce qui pousse régulièrement à ouvrir 115 en croyant autoriser le transfert SSH.

La différence se paie surtout côté réseau. FTP et FTPS ont besoin d’un canal de contrôle et d’un canal de données distincts, donc d’une plage de ports passifs à ouvrir et à déclarer au serveur (typiquement quelques dizaines de ports au-dessus de 40000). SFTP multiplexe tout dans la connexion TCP du port 22 : une seule règle de pare-feu, et rien à faire de particulier derrière un NAT.

Protocole	Transport	Ports TCP	Chiffrement
SFTP (SSH File Transfer)	Canal SSH	22	Toujours, hérité de SSH
SCP	Canal SSH	22	Toujours
FTP	TCP direct	21 contrôle, 20 données en mode actif	Aucun
FTPS explicite (AUTH TLS)	TLS après connexion	21 + plage passive	TLS négocié
FTPS implicite	TLS dès l’ouverture	990 contrôle, 989 données	TLS
Simple File Transfer Protocol (RFC 913)	TCP direct	115	Aucun, obsolète

Déplacer le service sur un autre port

Rien n’oblige à rester sur 22. Dans /etc/ssh/sshd_config, la directive Port 2222 suffit, puis systemctl restart ssh. Gardez votre session en cours ouverte pendant le redémarrage : si la nouvelle configuration est mauvaise, elle reste votre seul accès.

Deux détails font perdre du temps. Sur Ubuntu depuis la 22.10, sshd est activé par socket : modifier Port dans sshd_config n’a plus aucun effet, il faut éditer l’unité (systemctl edit ssh.socket) et y placer ListenStream=2222. Sur RHEL, Rocky et AlmaLinux, SELinux refuse un port non déclaré, d’où semanage port -a -t ssh_port_t -p tcp 2222 avant tout redémarrage.

Côté client, l’option n’a pas la même casse selon l’outil : ssh -p 2222, mais sftp -P 2222 et scp -P 2222. La méthode qui évite l’erreur consiste à écrire une fois le port dans ~/.ssh/config sous forme d’un bloc Host, car sftp et scp appellent ssh et lisent ce fichier. Les trois commandes tombent alors d’accord toutes seules.

Changer de port réduit le bruit dans les journaux, pas la surface d’attaque réelle : un scan complet retrouve le service en quelques secondes. Le gain est cosmétique, l’authentification par clé et la limitation des tentatives comptent davantage.

• sshd_config : Port 2222 (et ListenAddress si vous voulez lier une seule interface)
• Ubuntu 22.10 et suivantes : systemctl edit ssh.socket, ListenStream=2222
• RHEL et dérivés : semanage port -a -t ssh_port_t -p tcp 2222
• Client : sftp -P 2222, ou un bloc Host dans ~/.ssh/config

Tester et filtrer le port

Sur le serveur, ss -lntp affiche les sockets en écoute avec le processus associé : une ligne LISTEN sur 0.0.0.0:22 avec users:(("sshd",…)) confirme que le démon écoute sur toutes les interfaces. Depuis l’extérieur, nc -vz serveur 22 distingue en une seconde un port fermé (connection refused, un service manque) d’un port filtré (la commande reste bloquée jusqu’au délai d’expiration, un pare-feu jette les paquets).

Quand le port répond mais que le transfert échoue, sftp -vvv utilisateur@serveur donne la réponse dans les vingt dernières lignes : requête subsystem refusée, clé d’hôte rejetée, ou authentification en boucle. Le journal serveur, journalctl -u ssh, dit la même chose vue de l’autre côté.

Un cas de panne revient souvent sur les serveurs de dépôt automatisés. Les réglages OpenSSH par défaut sont LoginGraceTime 120 et MaxStartups 10:30:100 : au delà de 10 connexions non encore authentifiées en attente, le serveur commence à en refuser 30 % au hasard, et coupe tout à 100. Un script qui lance 40 sftp en parallèle voit donc une partie des sessions se fermer sans motif apparent, ce qui ressemble à un problème de port alors que c’est une limite de concurrence.

Les pannes qui ressemblent à un problème de port

La plus fréquente concerne le confinement des utilisateurs. Avec ChrootDirectory /home/%u et ForceCommand internal-sftp dans un bloc Match Group, la session se ferme immédiatement après l’authentification si le répertoire de confinement n’appartient pas à root ou s’il est accessible en écriture au groupe. Le client affiche « Connection closed by remote host », le journal du serveur est plus bavard : « fatal: bad ownership or modes for chroot directory ». Le correctif tient en deux commandes, chown root:root sur le répertoire et chmod 755, l’utilisateur n’écrivant que dans un sous-dossier.

Toujours dans un chroot, la ligne Subsystem doit pointer vers internal-sftp et non vers un binaire externe : le processus confiné n’a plus accès à /usr/lib/openssh/sftp-server, faute des bibliothèques nécessaires.

Autre fausse piste : le message REMOTE HOST IDENTIFICATION HAS CHANGED n’indique pas un port bloqué mais une clé d’hôte différente de celle mémorisée dans ~/.ssh/known_hosts, après une réinstallation ou un changement d’IP derrière un répartiteur. Vérifiez l’empreinte auprès de l’hébergeur avant de supprimer la ligne, c’est exactement le scénario que cette alerte est censée détecter.

Enfin, une session qui s’ouvre correctement puis se fige pendant un gros transfert relève plutôt du chemin réseau que du filtrage : MTU mal ajustée sur un tunnel, ou marquage QoS des paquets SSH mal digéré par un équipement intermédiaire. L’option de contournement documentée par OpenSSH est de forcer -o IPQoS=throughput côté client, à tester avant d’aller modifier des règles de pare-feu.

Questions fréquentes

Le SFTP utilise-t-il le port 21 ?

Non. Le 21 est le canal de contrôle du FTP, et de FTPS en mode explicite. Le SFTP, lui, passe par le port 22 puisqu’il s’agit d’un sous-système de SSH. Un serveur qui accepte du SFTP sur le 21 est en réalité un serveur FTPS, avec un logiciel et des identifiants différents.

Faut-il ouvrir des ports de données supplémentaires comme en FTP ?

Non, et c’est le principal avantage opérationnel du SFTP. Commandes, données et messages d’erreur circulent dans des canaux multiplexés à l’intérieur de la même connexion TCP sur le port 22. Une seule règle de pare-feu suffit, contre un port de contrôle plus une plage passive pour FTPS.

Pourquoi mon scanner de ports affiche-t-il sftp sur le port 115 ?

Parce que la plupart des outils lisent le fichier /etc/services, qui reprend le registre IANA. Le nom sftp y désigne Simple File Transfer Protocol, décrit par le RFC 913 en 1984 et sans rapport avec SSH. Ouvrir le 115 n’autorise donc aucun transfert SFTP.

Peut-on lancer SFTP sur un autre port sans casser SSH ?

Les deux partagent le même démon, donc pas séparément avec une configuration standard : déplacer le port déplace aussi les connexions shell. Il est possible de lancer une seconde instance de sshd avec son propre fichier de configuration et son propre port, dédiée au transfert de fichiers, avec ForceCommand internal-sftp et un groupe d’utilisateurs restreint.

Le port 22 doit-il être ouvert en UDP ?

Non. L’IANA réserve 22 en TCP et en UDP, mais OpenSSH n’écoute qu’en TCP. Une règle UDP sur 22 n’apporte rien et un scan UDP de ce port ne renverra jamais de service.

Testez vos connaissances

À lire aussi

chiffrement asymetrique · brute force · attaque man in the middle · certificat ssl