Un serveur SSH exposé sur le port 22 encaisse plusieurs milliers de tentatives de connexion automatisées par jour, souvent dès la première heure de mise en ligne. Pourtant, la majorité des serveurs SFTP que je dépanne ne tombent pas à cause d’une attaque, mais d’une erreur de permissions qui ferme la connexion en six secondes. Monter un serveur SFTP propre prend vingt minutes. Le faire sans se tirer une balle dans le pied en demande un peu plus de méthode. Voici exactement comment je procède.
Ce dont vous avez besoin avant de commencer
Bonne nouvelle : il n’y a presque rien à installer. SFTP n’est pas un logiciel séparé, c’est un sous-système livré avec OpenSSH. Si votre serveur accepte déjà les connexions SSH, le serveur SFTP est déjà là, il ne reste qu’à le configurer.
Côté matériel, un simple VPS à 3 à 6 € par mois suffit pour héberger plusieurs utilisateurs et quelques dizaines de gigaoctets de transferts. Inutile de viser un serveur dédié tant que vous restez sous les 10 comptes actifs. Vous aurez besoin d’un accès root ou sudo, et d’un client comme FileZilla côté poste de travail (transfert par glisser-déposer, fichiers jusqu’à 4 Go sans broncher).
Un repère utile : ne touchez jamais directement au fichier /etc/ssh/sshd_config sans avoir une seconde session SSH ouverte en parallèle. Une faute de frappe dans ce fichier peut vous verrouiller hors de votre propre serveur.
Étape 1 : créer un groupe et des utilisateurs dédiés
Je commence toujours par un groupe spécifique, jamais en réutilisant des comptes système existants. Cela isole les utilisateurs SFTP du reste de la machine.
groupadd sftpusers
useradd -g sftpusers -s /usr/sbin/nologin client1
passwd client1
Le détail qui compte : le shell /usr/sbin/nologin. Il interdit toute ouverture de session interactive. Un compte SFTP n’a aucune raison de pouvoir exécuter des commandes sur le serveur. Sauter cette ligne, c’est offrir un shell complet à quelqu’un qui ne devait que déposer des fichiers.
Étape 2 : configurer le chroot sans déclencher le blocage
C’est ici que 80 % des installations échouent. Le chroot enferme chaque utilisateur dans son répertoire, sans visibilité sur le reste du système. La règle qu’OpenSSH impose est contre-intuitive : le dossier de cloisonnement et tous ses dossiers parents doivent appartenir à root et ne pas être accessibles en écriture au groupe ni aux autres.
Concrètement, l’utilisateur ne peut pas posséder son propre répertoire chroot. S’il le possède, ou si le dossier est en chmod 777, la connexion se ferme aussitôt avec un message du type « connection closed » sans la moindre explication. La solution tient en deux niveaux : un dossier racine verrouillé en root, et à l’intérieur un sous-dossier inscriptible qui, lui, appartient au client.
mkdir -p /sftp/client1/depot
chown root:root /sftp /sftp/client1
chmod 755 /sftp /sftp/client1
chown client1:sftpusers /sftp/client1/depot
chmod 700 /sftp/client1/depot
On ajoute ensuite à la fin de sshd_config :
Match Group sftpusers
ChrootDirectory /sftp/%u
ForceCommand internal-sftp
AllowTcpForwarding no
X11Forwarding noJ’utilise toujours internal-sftp plutôt que l’ancien binaire sftp-server. Étant intégré au démon SSH, il fonctionne dans un environnement cloisonné sans qu’on ait à y copier de bibliothèques, là où l’ancienne méthode obligeait à recréer un mini système de fichiers dans la prison.
Erreurs fréquentes à éviter
- Connexion fermée en 5-6 secondes : neuf fois sur dix, un dossier parent du chroot n’appartient pas à root ou dépasse
chmod 755. Remontez toute l’arborescence avecls -ld.- L’utilisateur voit la racine
/: le blocMatch Groupest mal placé, ousshdn’a pas été redémarré. Vérifiez avecsshd -tavant toutsystemctl restart ssh.- Le client peut se connecter mais rien déposer : le dossier racine du chroot appartient à root (normal), mais vous avez oublié le sous-dossier inscriptible. Le client écrit dans
depot, pas à la racine.
Étape 3 : passer aux clés SSH et couper les mots de passe
Tant que l’authentification par mot de passe reste active, votre serveur reste vulnérable aux attaques par force brute, peu importe la complexité du mot de passe. Désactiver les mots de passe au profit des clés SSH supprime purement et simplement cette surface d’attaque. C’est, de loin, la mesure la plus efficace de tout cet article.
Dans un environnement chroot, le placement de la clé pose souvent problème. Je préfère sortir les clés autorisées de la prison en les centralisant côté serveur :
AuthorizedKeysFile /etc/ssh/keys/%u
PasswordAuthentication noOn dépose alors la clé publique du client dans /etc/ssh/keys/client1, hors d’atteinte de l’utilisateur. Avantage concret : le client ne peut pas modifier la liste des clés qui lui donnent accès, ce qui évite toute escalade silencieuse.
Avant de couper les mots de passe, testez une connexion par clé depuis une autre fenêtre. Se verrouiller dehors après avoir désactivé PasswordAuthentication reste le grand classique du week-end gâché.
Étape 4 : verrouiller l’accès contre les attaques
Beaucoup conseillent de changer le port 22. C’est utile, mais à comprendre pour ce que c’est : passer en port 2222 réduit le bruit des scans automatiques de 90 % environ, sans rien apporter en sécurité réelle. Un attaquant qui scanne les 65 000 ports trouvera le vôtre.
La vraie barrière, c’est Fail2ban. L’outil surveille les journaux et bannit une IP après trois échecs, en général pour 30 minutes. Sa limite est connue : les attaques modernes font tourner des centaines d’adresses depuis des proxys résidentiels, ce qui contourne un bannissement par IP isolée. Fail2ban réduit donc surtout le bruit. Combiné à une authentification par clé seule, il devient presque superflu pour la sécurité, mais reste précieux pour garder des journaux lisibles.
L’empilement que j’applique systématiquement : pare-feu n’ouvrant que le port SSH, clés uniquement, et Fail2ban par-dessus. Aucune couche n’est suffisante seule, leur combinaison rend une intrusion exponentiellement plus coûteuse.
SFTP, FTPS ou solution clé en main ?
Si un partenaire vous impose FTPS, gardez en tête le coût caché : FTPS utilise deux canaux (port 21 pour les commandes, port 990 ou une plage passive pour les données), ce qui transforme la configuration du pare-feu et du NAT en casse-tête. SFTP, lui, fait tout passer par un seul port, ce qui simplifie radicalement les règles réseau. À sécurité comparable, SFTP gagne sur la simplicité d’exploitation. FTPS ne se justifie que face à un client legacy ou une exigence de certificat X.509.
Quand le pilotage manuel de sshd_config devient pénible (multiplication des comptes, quotas, stockage sur S3 ou Azure), une solution comme SFTPGo prend le relais. Ce serveur open source ajoute une interface d’administration web, l’authentification multifacteur, des quotas par utilisateur et la limitation de bande passante, tout en se branchant sur des stockages objet distants. Pour un usage personnel ou trois comptes, OpenSSH suffit largement. Au-delà d’une dizaine d’utilisateurs à gérer au quotidien, l’interface graphique fait gagner un temps réel.
FAQ
Un serveur SFTP fonctionne-t-il sous Windows ?
Oui. Depuis Windows 10 et Windows Server, OpenSSH s’installe comme fonctionnalité optionnelle. Vous téléchargez OpenSSH, ouvrez le port SSH, et le service SFTP devient disponible. La configuration du chroot reste toutefois plus rustique que sous Linux, où le bloc Match Group fait tout le travail.
SFTP est-il vraiment plus sûr que FTPS ?
Les deux chiffrent les transferts de bout en bout, et aucun n’est faillible par conception. SFTP s’appuie sur SSH, FTPS sur SSL/TLS. La différence pratique tient à l’exploitation, pas à la robustesse du chiffrement : moins de ports à gérer côté SFTP, donc moins d’occasions de mal configurer une règle qui ouvre une brèche.
À vous de jouer
Lancez l’installation sur un VPS de test avant de toucher à votre serveur de production. Créez un compte, vérifiez le chroot, basculez sur les clés, puis ouvrez une seconde session pour confirmer que tout tient avant de couper les mots de passe. Cette précaution de quelques secondes vous épargne le scénario le plus frustrant : un serveur impeccablement sécurisé, dont vous êtes le premier à être exclu.
