SFTP port TCP 22 : le port utilisé par le protocole SFTP expliqué pour les réseaux informatiques
Le SFTP s’est imposé comme la solution de référence quand on veut transférer des fichiers de façon sécurisée sur un réseau. Et franchement, une des premières choses qu’on vérifie en pratique, c’est le port. Le SFTP utilise le port TCP 22 par défaut, le même que SSH. C’est pas juste une convention : c’est le résultat d’une architecture pensée pour simplifier la vie des administrateurs réseau.
Le port SFTP TCP par défaut et son fonctionnement
Le port SFTP TCP est donc le 22. L’IANA l’a attribué à SSH il y a belle lurette, et SFTP fonctionne comme un sous-système de SSH. Résultat : une seule connexion TCP sur ce port suffit pour tout. Authentification (clés ou mot de passe), envoi de commandes, transfert des données, reprise après coupure… tout passe par le même canal chiffré. Pas de négociation secondaire, pas de port qui s’ouvre à la volée.
C’est là que le côté TCP prend tout son sens. Le protocole SSH a été conçu pour des sessions fiables et persistantes. TCP garantit l’ordre des paquets, la retransmission automatique en cas de perte et la détection d’erreurs. Pour des fichiers, surtout quand ils font plusieurs centaines de méga ou des giga, on a besoin de cette fiabilité. UDP, lui, reste dans son coin pour du DNS ou du streaming léger où on accepte de perdre un paquet de temps en temps. Ici, on n’accepte pas.
Pourquoi le FTP utilisait le port 21 et pourquoi c’était plus compliqué
Le FTP historique, lui, écoute sur le port 21 TCP pour le canal de contrôle. Dès qu’on veut vraiment bouger des données, il ouvre un second canal : soit le serveur initie la connexion vers le client sur le port 20 (mode actif), soit le client propose un port haut en mode passif. Dans les deux cas, le pare-feu doit autoriser des ports dynamiques ou une plage entière. Avec les NAT, les firewalls stateful et les règles strictes d’aujourd’hui, ça devient vite un casse-tête. On passe son temps à ouvrir des trous ou à configurer des helpers FTP qui ne marchent pas toujours.
Le SFTP port TCP 22 évite complètement ce cirque. Tout reste dans la même connexion. Du coup, la règle pare-feu est limpide : on autorise TCP 22 entrant sur le serveur (et sortant si on est client) et c’est fini. C’est pour ça que dans pas mal d’environnements cloud ou hybrides, on bascule naturellement vers SFTP.
FTPS et ses ports : la même logique FTP, avec plus de complexité
Le FTPS (FTP over TLS) garde la structure du FTP. En mode implicite on parle souvent du port 990 pour le contrôle, parfois 989 pour les données. En mode explicite on commence sur 21 puis on upgrade avec AUTH TLS. Mais on conserve toujours ce double canal, et donc cette histoire de ports dynamiques à négocier. Les firewalls qui ne peuvent pas décrypter le trafic ont du mal à suivre. On se retrouve avec des règles plus larges qu’on ne le voudrait, ou des transferts qui bloquent sans raison claire.
SFTP, lui, n’a rien à voir avec cette lignée. C’est du SSH pur. Un tunnel unique, chiffré de bout en bout, avec authentification par clés possible. Moins de surface d’exposition, moins de surprises en production.
Les vrais avantages réseau du port unique TCP 22
Quand on gère des échanges entre datacenters, des backups automatisés ou des flux partenaires, le port SFTP TCP 22 change la donne côté infrastructure. Une seule règle à documenter et à monitorer. Meilleure compatibilité avec les NAT et les VPN. Et tout le trafic est déjà protégé par les algorithmes de SSH (généralement AES-256-GCM ou équivalent aujourd’hui). Pas besoin de rajouter une couche TLS par-dessus comme on le fait parfois avec FTPS.
Dans la pratique, avec un client comme FileZilla ou WinSCP, on se connecte en indiquant juste le port 22 (ou en le laissant par défaut). En ligne de commande, un simple sftp user@serveur suffit la plupart du temps. Pour les scripts Ansible ou les pipelines CI, c’est tout aussi direct.
Changer le port SFTP : comment faire et quand c’est utile
On peut tout à fait faire tourner SFTP sur un autre port. Sur un serveur Linux avec OpenSSH, on édite /etc/ssh/sshd_config, on ajoute ou modifie la ligne Port 2222, on sauvegarde puis on relance le service avec systemctl restart sshd. Il faut bien sûr autoriser ce nouveau port sur le pare-feu (ufw allow 2222/tcp ou équivalent dans le Security Group AWS). Côté client, on précise le port avec -P 2222 en ligne de commande ou dans l’interface graphique.
Le truc, c’est que ce n’est pas toujours le meilleur plan. Les ports non standards attirent parfois plus l’attention des scanners automatiques. Certains environnements proxy ou filtrés les bloquent par défaut. Et il faut penser à mettre à jour tous les scripts, les documentations et les règles de monitoring. Franchement, je préfère souvent garder le 22 et durcir la config SSH (désactiver l’authentification par mot de passe, restreindre les utilisateurs autorisés, activer fail2ban ou équivalent). Moins de surprises.
Les questions qui reviennent souvent sur le port SFTP TCP
Beaucoup demandent si le port 22 est TCP ou UDP. C’est TCP, sans ambiguïté. L’assignation UDP 22 existe dans les registres IANA, mais SSH et SFTP ne l’utilisent pas. Le protocole a besoin de la fiabilité de TCP.
Le port 21, lui, reste celui du FTP classique, en clair. On l’évite aujourd’hui sauf sur des réseaux complètement isolés du reste du monde.
Et la différence avec HTTPS ? HTTPS tourne sur le 443 TCP et sécurise l’accès web, les APIs, les navigateurs. SFTP sert au transfert et à la gestion de fichiers distants (lister, renommer, supprimer, reprendre un transfert). Ce sont deux outils pour deux usages différents, même s’ils chiffrent tous les deux le trafic.
Au bout du compte, pour des transferts de fichiers sécurisés, fiables et simples à faire passer à travers les pare-feu modernes, le SFTP sur son port TCP 22 reste un choix solide. Moins de ports à gérer, un chiffrement natif robuste, et une compatibilité large avec les outils du marché. Quand on conçoit ou qu’on audite une infrastructure réseau, c’est souvent le point de départ le plus propre.
