Guide des ports SFTP : transfert de fichiers sécurisé via SSH

SFTP n'est pas FTP avec un cryptage ajouté en haut. Il s'agit d'un protocole distinct qui s'exécute au sein d'une session SSH. Le client se connecte au serveur SSH, s'authentifie avec un mot de passe, une clé, un certificat ou une autre méthode prise en charge par SSH, puis démarre le sous-système SFTP pour répertorier les répertoires, télécharger des fichiers, renommer les chemins et gérer les autorisations.

Étant donné que SFTP repose sur SSH, il bénéficie du cryptage SSH, de la vérification de la clé hôte et de contrôles d'authentification avancés. Pour la plupart des déploiements, le port SFTP est donc TCP 22. Certaines organisations déplacent SSH et SFTP vers un autre port pour réduire le bruit d'analyse en arrière-plan, mais le changement de port ne remplace pas les contrôles d'authentification et d'autorisation.

FTP classique utilise généralement le port 21 pour les commandes et des ports de données séparés pour les transferts. Cela rend le pare-feu et le NAT plus complexes, et le simple FTP envoie les informations d'identification et les données sans cryptage. FTPS ajoute TLS à FTP, mais il conserve toujours le modèle FTP avec des canaux de commande et de données.

SFTP utilise une connexion SSH, qui est généralement plus facile à autoriser via les pare-feu et à auditer. SCP utilise également SSH, mais SFTP offre des opérations de gestion de fichiers plus riches et constitue la meilleure valeur par défaut pour les transferts interactifs, les abandons de partenaires et les flux de travail de fichiers automatisés.

Ouvrez l'accès SFTP lorsqu'un partenaire, une tâche d'automatisation, un processus de sauvegarde, un pipeline de déploiement ou une équipe interne a besoin d'échanger des fichiers en toute sécurité avec un serveur. Les exemples courants incluent les flux de données des fournisseurs, les exportations nocturnes, la collecte de journaux, la livraison sécurisée de documents et les zones de téléchargement contrôlées pour les clients ou les appareils de terrain.

N'exposez pas SFTP à grande échelle simplement parce qu'il est chiffré. Un service SSH accessible sur Internet attire les attaques d’identifiants et l’analyse automatisée. Si seul un petit groupe a besoin d'accéder, limitez les adresses IP sources, publiez SFTP derrière un VPN ou un réseau privé, ou utilisez une passerelle de transfert gérée avec des contrôles de politique plus stricts.

Avant d'ouvrir le port 22 pour SFTP, vérifiez que le serveur SSH est installé, en cours d'exécution et configuré pour autoriser le sous-système SFTP. Décidez ensuite quels utilisateurs ou comptes de service doivent se connecter, quels répertoires ils peuvent voir, si l'authentification par mot de passe est autorisée et comment les téléchargements seront enregistrés.

Séparez l'accessibilité du réseau de l'autorisation du compte. Un vérificateur de port peut montrer si TCP 22 est accessible depuis Internet, mais il ne peut pas prouver qu'un utilisateur spécifique peut se connecter ou qu'un répertoire chroot est correct. Utilisez un client SFTP ou des tests de ligne de commande ssh pour vérifier le comportement au niveau de l'application.

Sur Windows Server, installez et activez le serveur OpenSSH, autorisez TCP 22 entrant dans le pare-feu Windows Defender et confirmez que le service sshd est en cours d'exécution. Si le serveur se trouve dans un environnement cloud, autorisez également le port 22 dans le pare-feu cloud ou le groupe de sécurité. Utilisez des comptes dédiés plutôt qu’un accès administrateur étendu.

Sous Linux, installez OpenSSH Server, confirmez que sshd écoute sur le port 22 et assurez-vous que le sous-système SFTP est activé dans sshd_config. Pour les comptes de transfert de fichiers restreints, configurez les répertoires chroot, les règles de propriété et ForceCommand internal-sftp afin que les utilisateurs ne puissent pas obtenir un shell interactif.

Sur macOS, SFTP est disponible via le service SSH intégré. Il est le plus souvent utilisé pour les réseaux locaux, les machines de développement ou les environnements de laboratoire. Si vous l'exposez au-delà d'un réseau approuvé, appliquez les mêmes règles d'authentification par clé et de pare-feu que vous utiliseriez sur un serveur.

Commencez par une vérification du port externe par rapport au nom d'hôte public ou à l'adresse IP et au port 22. Si le port est ouvert, le chemin TCP vers le service SSH est accessible. Ensuite, utilisez un client SFTP ou exécutez sftp user@example.com pour vérifier l'authentification, la confiance de la clé hôte, l'accès au répertoire et les autorisations de téléchargement.

Si vous avez besoin de détails de niveau inférieur, testez la négociation SSH avec ssh -vvv user@example.com ou vérifiez les écouteurs sur le serveur avec ss -tlnp, netstat ou PowerShell. Pour les serveurs cloud, comparez les règles de pare-feu hôte avec les groupes de sécurité cloud, car les deux couches doivent autoriser la connexion.

Si le port SFTP est fermé, sshd n'est peut-être pas en cours d'exécution, peut être en train d'écouter sur un autre port ou peut être bloqué par le pare-feu hôte. Si la vérification expire, un groupe de sécurité cloud, une règle NAT de routeur, un filtre de FAI, une stratégie VPN ou une liste blanche d'adresse IP source peuvent supprimer des paquets avant qu'ils n'atteignent le serveur.

Si le port est ouvert mais que la connexion SFTP échoue, inspectez le nom d'utilisateur, les autorisations de clé, la politique de mot de passe, les exigences MFA, les utilisateurs autorisés, la propriété du chroot, les règles ForceCommand et les journaux du serveur. Une erreur courante consiste à accorder à un répertoire chroot des autorisations d'écriture pour l'utilisateur ; OpenSSH nécessite des modèles de propriété et d'autorisation spécifiques pour que chroot fonctionne en toute sécurité.

Préférez les clés SSH ou l'authentification par certificat aux mots de passe. Désactivez la connexion root, limitez les utilisateurs pouvant se connecter, alternez les clés, supprimez les comptes inutilisés et protégez les clés privées avec des phrases secrètes ou un stockage matériel. Pour l'accès partenaire, créez un compte par partenaire afin que l'activité puisse être attribuée et révoquée proprement.

Restreignez l'accès au système de fichiers avec un chroot ou des répertoires à portée étroite, évitez les dossiers partagés inscriptibles à moins qu'ils ne soient requis et surveillez les échecs de connexion et les volumes de transfert inhabituels. Si SFTP est accessible sur Internet, combinez la limitation du débit, les listes autorisées de sources, la détection d'intrusion et l'application régulière de correctifs au serveur SSH.