Linux : configuration d’un espace de stockage sécurisé avec SFTP
Sommaire
I. Présentation
Dans ce tutoriel, je vais vous expliquer comment mettre en place un système de stockage de fichier sécurisé par l’isolation de chaque utilisateur et le chiffrement des connexions. Autrement dit, nous allons permettre à différents utilisateurs de bénéficier d’un espace de stockage dédié et isolé sur notre serveur, au travers d’une connexion SFTP.
SFTP (pour Secure File Transfert Protocol) est un protocole de transfert de fichier sécurisé qui utilise SSH. Un des gros avantages de FTP est qu’il est simple à déployer et à utiliser ; à l’inverse, il est par nature non sécurisé dans le sens où tout passe en clair sur le réseau, y compris les mots de passe !
SFTP quant à lui, assure un chiffrement dès l’authentification, il permet ainsi d’assurer la sécurité des accès et des données qui transitent. En revanche, il nécessite plus de travail de mise en place et bien que nativement prit en charge dans Windows 10 depuis l’ajout du support OpenSSH, il est plus aisé d’utiliser un logiciel tel que WinScp ou Filezilla. Pour la sauvegarde, vous pouvez utiliser FullSync qui gère les connexions SFTP.
Pour ce tuto, j’ai utilisé un serveur Rocky Linux en installation minimale (pas besoin de plus) et le client OpenSSH de Windows pour la connexion SSH, mais vous pouvez utiliser un logiciel tiers comme PuTTY par exemple.
Bien entendu, ce tuto est reproductible sur CentOS, AlmaLinux ou Oracle Linux tel quel. Pour les utilisateurs de Debian, des notes viennent indiquer les changements de commandes et/ou de chemins de fichiers.
II. Préparation du serveur
A. Configuration du réseau
La première chose à faire bien entendu est d’adresser notre serveur en statique. Comme il s’agit d’un serveur de fichier, il n’est pas concevable de le laisser en dynamique au risque de voir son IP changer !
La gestion des adresses IP sur Linux varie en fonction de la distribution. Par chance sur CentOS, il existe un utilitaire qui permet de faire cela en un rien de temps : NetworkManager TUI
Il suffit donc de taper la commande :
[root@sftp ~]# nmtui
Un menu nous permet alors de définir notre adresse IP en statique. Dans un premier temps, sélectionnez « Modifier une connexion »
Puis de sélectionner l’interface correspondante (pour moi c’est facile, il n’y en a qu’une, mais attention si vous en avez plusieurs) et choisir « Modifier… »
Dans la fenêtre suivante, il faut vous rendre dans « CONFIGURATION IPv4 » pour le changer en « Manuel » puis sélectionner « Afficher ».
Ici, mon réseau étant en 192.168.1.0/24, je choisis l’adresse 192.168.1.100. Bien entendu, vous faites comme vous le souhaitez tant que votre adresse reste dans votre plage.
Au passage, vérifiez bien que la case « Connecter automatiquement » est bien cochée, cela vous évitera des déconvenues…
Note : les utilisateurs de Debian n’auront pas la chance d’avoir ce menu. Pour ceux-ci ou les aficionados de la ligne de commande, je vous laisse suivre les excellents tutos sur ifconfig ou iproute2 en fonction de vos systèmes.
Une fois tout ceci validé, un petit redémarrage des services réseau pour la prise en compte des modifications :
[root@sftp ~]#systemctl restart network # Sous Debian : systemctl restart networking
Et pour valider le changement, on va afficher le résultat de la commande ip a.
Notre serveur est bien adressé, on peut passer à la suite.
B. Vérification de la présence du service SSH
Toutes les distributions Linux viennent avec un client SSH ; la plupart avec un serveur SSH, mais celui-ci n’est pas forcément installé par défaut. Ou encore, il m’arrive également de sauter l’étape correspondante lors de l’installation donc on va déjà vérifier qu’il est bien installé :
[root@sftp ~]#systemctl status sshd
Voici le retour pour moi :
Le service est bien installé et même actif.
Si vous avez un retour de ce genre :
Unit sshd.service could not be found
Pas de chance, c’est que le service n’est pas présent ! Mais pas de panique, on peut l’installer à tout moment grâce à la commande magique :
[root@sftp ~]#yum install -y sshd
Yum est le gestionnaire de paquet pour toutes les distributions dérivées de Red Hat comme le son Rocky, Alma et CentOS, cette commande appelle donc l’installation d’OpenSSH ; l’option « -y » permet d’éviter le prompt de validation.
Note : les utilisateurs de Debian avertis auront ici compris qu’il faut utiliser le gestionnaire de paquet Debian « apt ». La commande devient donc apt-get install -y sshd
C. Mise à jour du système
Donc avant tout, on va déjà se connecter, sur mon PC Windows, j’ouvre une fenêtre PowerShell et utilise la commande suivante :
ssh [email protected]
Si la fonctionnalité SSH n'est pas installée sur votre machine Windows, suivez ce tutoriel : le client SSH sous Windows.
Où « florian» est le nom d’utilisateur (à remplacer bien entendu par le vôtre). Une fois connecté, une petite mise à jour, ça ne fait pas de mal surtout maintenant que le serveur n’est pas encore entré en production. Mais pour cela, il faut se connecter en root avec la commande « su ».
[florian@sftp ~]$ su Mot de passe :
Au passage, vous pouvez constater que ma machine s’appelle « sftp », bien entendu, cela n’a aucune influence sur la suite du programme, vous pouvez la nommer comme vous voulez.
Une fois ceci fait, tapez la commande « yum update » :
[florian@sftp ~]$ su Mot de passe : [root@sftp florian]# yum update
Dépendances résolues.
Là je n’en ai pas beaucoup, mais cela peut être différent chez vous, donc prévoir un petit temps pour compléter toutes les mises à jour.
Note : les systèmes Debian nécessitent deux étapes pour faire une mise à jour de paquets. D’abord la commande apt-get update pour la mise à jour des dépôts puis apt-get upgrade pour la mise à jour des paquets
III. Mise en place du service
Ce qu’il y a de bien avec SFTP, c’est qu’on peut utiliser ce qu’on appelle une prison chroot (chroot jail). L’appel système « chroot » permet de changer le répertoire racine d’un processus ou d’un utilisateur. On parle de prison, car, lorsqu’il est utilisé, l’utilisateur (ou le processus) à l’impression d’être à la racine du système et donc de n’avoir aucun répertoire au-dessus de celui dans lequel il se trouve.
Cela a ses avantages, car il permet, dans un contexte multi-utilisateur, de ne faire apparaître à l’utilisateur uniquement SES répertoires, il ne pourra pas afficher ceux du voisin. Autre avantage, même si un utilisateur se fait piquer son mot de passe, le voleur n’ira pas bien loin et ne pourra corrompre la totalité du serveur.
On va ajouter à cela l’impossibilité pour un utilisateur d’ouvrir un shell sur le serveur. De base, SFTP est une « variante » de SSH donc en théorie, l’utilisateur pourra ouvrir une ligne de commande, mais ça, on ne veut pas !
Vu qu’on va pas mal manipuler les fichiers de configuration, je vais vous éviter l’utilisation de vi, j’aimerais que ce tuto soit reproductible par le plus grand nombre. On va donc installer nano, pour cela, on se connecte en root puis on tape la commande :
[root@sftp ~]#yum install -y nano
Pour Debian, l’éditeur nano est présent nativement. Pour vous en assurer, vous pouvez utiliser la commande « nano --version ».
Une fois l’installation terminée, l’éditeur de texte est prêt à l’emploi.
A. Empêcher la connexion de root via SSH
Ici, les utilisateurs Debian sont chanceux, l’implémentation de sshd dans cette distribution empêche d’office la connexion de root.
Il est indispensable de ne pas autoriser la connexion de cet utilisateur en SSH. Il faudra alors se connecter avec un utilisateur « lambda » et utiliser le compte root seulement quand nécessaire. Pour mettre cela d’aplomb, il faut aller modifier le fichier /etc/ssh/sshd_config avec nano.
[root@sftp ~]#nano /etc/ssh/sshd_config
Ce qui nous intéresse, ce sont ces lignes :
#Authentication: #LoginGraceTime 2m PermitRootLogin yes
On va tout simplement supprimer le « yes » de la dernière ligne pour le transformer en « no ». Une fois fait, on enregistre (Ctrl+o) et on quitte (Ctrl+x). Pour que cela soit pris en compte, on redémarre SSH :
[root@sftp ~]#systemctl restart sshd
B. Configuration SFTP
La première étape est de créer un groupe d’utilisateurs qui pourront se connecter en SFTP. Il sera ainsi plus facile de les gérer le cas échéant.
[root@sftp ~]#groupadd sftp
Encore une fois, le nom « sftp » est celui que j’ai choisi pour mon groupe, vous pouvez l’appeler comme vous voulez.
La seconde étape consiste à créer un répertoire qui va servir de « home » aux utilisateurs sftp :
[root@sftp ~]#mkdir /sftp
Je choisis de le mettre à la racine « / » pour plus de facilité, notamment pour les scripts de sauvegardes. Bien entendu, vous pouvez le mettre où vous le souhaitez.
Là encore, vous le nommez comme vous le souhaitez. L’important est de lui donner les bons droits. En effet, il est IMPÉRATIF de donner la propriété à root ainsi que les droits d’écriture. Rappelez-vous il s’agit de faire croire à l’utilisateur qu’il est à la racine, dont seul root à les droits d’écriture. SI on tape la commande « ls -al / », on constate ceci :
drwxr-xr-x. 2 root root 6 20 juin 03:46 sftp
Ce n’est pas bon, car seul root doit avoir les droits complets (lecture, écriture, exécution r-w-x) or ici, les autres utilisateurs ont également les droits d’exécution. Pour modifier cela, il faut taper la commande :
[root@sftp ~]# chmod 750 /sftp
Les droits sous Linux pouvant être représenté par des chiffres (octal):
- r (read) = 4
- w (write) = 2
- x (execute) = 1
Et chaque bloc représente un utilisateur (propriétaire-groupe-autres). Donc à partir de là, 750 octroie les droits complets au propriétaire, lecture et exécution au groupe et rien aux autres.
Maintenant que la base est là, on va retourner dans la modification du fichier sshd_config :
[root@sftp ~]#nano /etc/ssh/sshd_config
Ce qui nous intéresse ici, ce sont les dernières lignes :
override default of no subsystems Subsystem sftp /usr/libexec/openssh/sftp-server Example of overriding settings on a per-user basis Match User anoncvs X11Forwarding no AllowTcpForwarding no PermitTTY no ForceCommand cvs server
Il est nécessaire de les modifier de la sorte (les explications viennent après) :
override default of no subsystems Subsystem sftp internal-sftp Example of overriding settings on a per-user basis Match Group sftp X11Forwarding no AllowTcpForwarding no PermitTTY no PermitTunnel no ForceCommand internal-sftp -d /upload ChrootDirectory /sftp/%u
Bien, décortiquons tout ça :
- Subsystem sftp internal-sftp va indiquer au démon sshd d’utiliser les commandes intégrées
- Match Group sftp va appliquer les lignes qui suivent à tous les utilisateurs faisant partie du groupe « sftp »
- X11Forwarding no va interdire la transmission de l’affichage entre le serveur et le client (ici nous n’avons pas d’interface graphique, mais il vaut mieux l’activer si d’aventure on en rajoute une)
- AllowTcpForwarding no va interdire les redirections TCP
- PermitTTY no va interdire l’utilisation du shell
- PermitTunnel no va interdire l’utilisation des commandes SSH pour créer des tunnels chiffrés
- ForceCommand internal-sftp va obliger les utilisateurs à n’utiliser QUE les commandes SFTP, l’option « -d /upload » va spécifier le répertoire dans lequel l’utilisateur arrive au moment de la connexion, ceci pour éviter qu’il n’arrive à sa racine, car il n’aura pas les droits d’écriture (voir plus bas)
- ChrootDirectory /sftp/%u va indiquer au démon que les utilisateurs doivent croire que la racine est /sftp/nomdelutilisateur
Il ne nous reste qu’à enregistrer et fermer, puis redémarrer sshd.
IV. Création des utilisateurs
On va créer maintenant notre premier utilisateur « john» avec une seule ligne de commande :
[root@sftp ~]#useradd -s /usr/bin/false -d /sftp/john -G sftp john
- L’option « -s » spécifie le shell à utiliser, on ne veut pas qu’il en utilise donc on lui indique un « faux » shell (en fait, c’est plutôt une commande qui ne fait rien et se termine avec un code d’erreur)
- L’option « -d » indique quel répertoire sera celui de l’utilisateur
- L’option -G ajoute l’utilisateur au groupe (ici sftp)
N’oubliez pas de lui affecter un mot de passe :
[root@sftp ~]#passwd john
Attention, par défaut, le répertoire « john » aura des permissions uniquement pour l’utilisateur john (et root bien entendu). Comme indiqué plus haut, pour que SFTP puisse fonctionner, il est obligatoire d’avoir des droits réglés sur 750 avec root en tant que propriétaire.
Il faut donc modifier le propriétaire du dossier. J’en profite pour déclarer « sftp » comme groupe propriétaire également et modifie les droits :
[root@sftp ~]#chown root:sftp /sftp/john [root@sftp ~]#chmod 750 /sftp/john
On ne peut pas s’arrêter ici, car l’utilisateur « john » pourra bien se connecter, mais en aucun cas uploader quoi que ce soit. Il faut donc lui créer un répertoire dans lequel il pourra à loisir uploader des fichiers, créer d’autres répertoires, etc.
Rappelez-vous, lors de la configuration du service, on a spécifié « ForceCommand internal-sftp -d /upload » donc le répertoire qui sera utilisé par l’utilisateur doit s’appeler « upload ».
[root@sftp ~]#mkdir /sftp/john/upload [root@sftp ~]#chown john:john /sftp/john/upload [root@sftp ~]#chmod 750 /sftp/john/upload
V. Tester le bon fonctionnement
Pour le test, j’utilise WinSCP que j’aime beaucoup, mais vous pouvez utiliser Filezilla sans problème. Pour rappel, Windows 10 permet l’utilisation de sftp nativement, mais en ligne de commande, WinSCP ou FileZilla ont l’avantage de représenter l’arborescence à la manière d’un Explorer ce qui facilite grandement la manipulation de fichiers et répertoires.
Il est fort probable qu’a la première connexion, vous ayez un message de ce type. Normal, le serveur est inconnu, donc le logiciel ne peut comparer sa clé à une autre en mémoire. Cliquer sur « Oui » pour continuer le processus de connexion.
Comme promis, nous arrivons immédiatement dans le répertoire « upload » où l’utilisateur a les droits d’écriture (répertoire courant en haut à gauche) :
Si on remonte d’un cran, on arrive à ce résultat :
Vous constaterez qu’il est bien indiqué « racine » en haut à gauche en guise de répertoire actuel, alors que nous savons bien que c’est faux ! D’ailleurs, si vous essayez de remonter dans l’arborescence, vous ne pourrez pas.
Comme annoncé également, il sera impossible de créer ou uploader quoi que ce soit dans le répertoire courant, mais dans « upload » pas de soucis, notre utilisateur pourra faire ce qu’il veut.
Et qu’en est-il de la connexion par SSH ?
ssh [email protected] [email protected]'s password: PTY allocation request failed on channel 0 This service allows sftp connections only. Connection to 192.168.1.100 closed.
Le message est on ne peut plus clair, seules les connexions et commandes sftp sont autorisées pour cet utilisateur. En revanche, pas de soucis pour mon utilisateur « florian » qui lui peut encore se connecter.
VI. Montage automatique du répertoire SFTP
Pour une utilisation ponctuelle ou une cible de sauvegarde, les étapes ci-dessus suffisent largement. En revanche, si on veut utiliser le répertoire sftp comme lecteur réseau par exemple, il est nécessaire de « monter » ce répertoire dans le système de fichier actuel pour l’utiliser comme s’il était directement attaché à notre machine.
Pour cela, il existe SSHFS, disponible sur toutes les distributions Linux et même sur Windows !
Note : je ne préconise pas de montage permanent ni sous Linux ni sous Windows. La création d’un tel serveur de fichier est à des fins de sécurité, or un montage permanent va à l’encontre de ce principe, surtout si l’utilisateur n’as pas de mot de passe de session par exemple.
A. Utilisation de SSHFS sous Linux
Retrouvez notre tutoriel dédié à SSHFS à cette adresse : Tutoriel SSHFS - Sinon, en résumé voici les étapes à suivre.
Pour tous ceux équipés d’une distribution desktop, rien de plus simple, il suffit d’installer le paquet sshfs sur leur machine à l’aide de la commande :
# Sur Debian apt install -y sshfs # Sur CentOS et dérivés yum install -y sshfs
Une fois l’installation faite, il faut créer un répertoire qui « accueillera » notre montage, ici, je décide que ce sera un dossier nommé sftp que je crée dans mon répertoire user :
mkdir /home/flo/sftp
Maintenant, il ne me reste plus qu’a utiliser la commande qui va bien :
sshfs [utilisateur@]serveur:[dossier distant] point_de_montage [options]
Soit dans mon cas :
sshfs [email protected]:/upload /home/flo/sftp Are you sure you want to continue connecting (yes/no/[fingerprint])? yes [email protected]'s password:
Une fois le mot de passe rentré, nous pouvons naviguer dans notre répertoire en local.
Note : n’oubliez pas que pour john, son répertoire est à la racine d’où le chemin « /upload » dans la commande sshfs. Si vous indiquez le VRAI chemin (/sftp/john/upload), cela ne fonctionnera pas !
Il est possible de monter ce répertoire en permanence via le fichier fstab en ajoutant la ligne :
[email protected]:/upload /home/flo/sftp fuse.sshfs defaults 0 0
La commande est identique à deux exceptions prêtes :
- fuse.sshfs : spécifie le système de fichier utilisé
- defaults : spécifie les options de montage, ici on laisse les options par défaut
- 0 0 : Ces deux chiffrent sont utiles pour la vérification des erreurs du système de fichier au démarrage. Le premier concerne la racine, le deuxième pour les partitions externes. Ici je ne veux pas de vérification, donc je mets les deux valeurs à « 0 »
Note : si vous voulez vraiment faire un montage automatique, il sera obligatoire de vous authentifier par clé. Le montage par fstab via une authentification par mot de passe n’est pas possible.
B. Utilisation de SSHFS sous Windows
SSHFS est également disponible sur Windows, un grand merci à Bill Zissimopoulos (billziss-gh) pour les deux installateurs disponibles sur GitHub qu’il faudra d’ailleurs récupérer :
Une fois l’installation de ces deux paquets, l’ajout du lecteur réseau est aussi simple qu’un partage SMB directement dans l’explorateur :
\\sshfs\[email protected]
Ici, pas besoin de spécifier de chemin, comme pour les connexions manuelles, l’utilisateur sera immédiatement « propulsé » dans son dossier « upload »
Si tout est OK, vous aurez la demande du mot de passe :
Et le répertoire est monté. Je vous invite grandement à lire le manuel de SSHFS-Win pour voir toutes les possibilités offertes par ce merveilleux utilitaire.
VII. Conclusion
Notre serveur est prêt, vous pouvez maintenant créer d’autres utilisateurs selon le modèle de john et constater qu’ils ne peuvent connaitre l’existence des autres, et encore moins accéder à leurs dossiers.
Nous avons donc vu comment mettre en place un serveur de fichier sécurisé, avec chiffrement des données échangées et isolation des utilisateurs par « enfermement » dans une racine virtuelle.
Avec les possibilités de montage sur Linux ou Windows, cela offre un réel plus, notamment si vous avez plusieurs « clients » que vous souhaitez leur offrir un espace personnel sécurisé pour leurs fichiers sensibles ou encore leurs sauvegardes.
