cClaude.rocks ☕ Le blog

Lorsque l’on fait des recherches sur le partage de dossier sous Linux, la solution la plus souvent proposée s’appuie sur des partages SAMBA.

Le problème est que SAMBA (ou SMB) n’a pas été pensé pour les systèmes Linux, mais est issue d’une veille technologie Microsoft comportant de nombreuses limitations vis-à-vis d’Unix.

Hormis la gestion des droits, le fait que les noms de fichiers ne soient pas sensibles à la casse (majuscules/minuscules) peut la source d’effets inattendus.

Le support du partage des fichiers sous Linux

Le système de partage natif sous Linux est NFS (Network File System), la gestion des droits est alors pleinement supportée, mais pour cela il faut que les utilisateurs soient déclarés sur toutes les machines concernées et avec le bon « mapping » (user_name/user_id et goup_name/goup_id), une contrainte qui dans certains cas est difficile à satisfaire, en particulier avec un NAS propriétaire (quelle que soit sa marque).

Il existe de nombreuses solutions pour échanger des fichiers, mais le choix de sshfs s’inscrit dans une solution permettant un accès aux fichiers à travers le système de fichier (« file system ») natif de la machine.

Par exemple une solution comme ftp ne correspond pas à cela, car vous ne pouvez pas avec n’importe quel logiciel atteindre un fichier stocké sur un serveur ftp.

Mais les solutions permettant de partager des partitions en fond partie, elles sont cependant sans doute plus adaptées à des besoins professionnels ou ponctuels :

• Network block device,
• Le ISCSI est typiquement une solution plutôt orientée professionnel et qui n’est pas destinée à partager des fichiers entre des machines mais plus à déporter des disques (des partitions).

sshfs

Pour ssh et fs, ce qui veut dire « système de fichier » (« File System ») sur ssh (« Secure Shell Protocol »).

Précision préalable

Ce billet ne prétend pas dire que sshfs est la solution ultime. Certaines fonctionnalités peuvent aussi bien être vues comme un avantage que comme un inconvénient.

Ce billet suppose que vous sachiez configurer ssh, en particulier créer une paire de clé dont la paire doit rester sur le client et la clé publique être définie dans le fichier ~/.ssh/authorized_keys de l’ordinateur serveur (le ~ indiquant le dossier personnel de l’utilisateur qui est à l’origine du partage).

Pourquoi utiliser sshfs ?

• Parce que SAMBA demande l’installation d’un service dédié, que la configuration et que le support des fonctionnalités Unix est partiel,
• Parce que NFS c’est contraignant et que la configuration se fait au niveau administrateur,
• Parce que sshfs ça doit s’utiliser dans un contexte utilisateur (pas en tant qu’utilisateur root) et que la configuration se fait par l’utilisateur qui effectue le partage.

Il est possible d’affiner la configuration en tant que root, en particulier durcir ("hardening") la sécurité au niveau de FUSE.

Précautions d’utilisation

Un utilisateur qui partage un accès ssh à un tiers, délègue tous ces droits sur la machine, y compris celui d’exécuter des applications.

sshfs est basé sur FUSE qui ne fait pas partie du noyau Linux, c’est pourquoi vous devez proscrire d’utiliser sshfs en root, afin de protéger votre machine d’éventuelle attaques.

Installation sur le serveur

ssh est requis, mais il est probablement déjà présent.
Concernant la configuration, il n’y a rien à faire pour sshfs proprement dit, mais ssh doit être fonctionnel.

Comme dis plus haut, l’objet de ce billet n’est pas la configuration de ssh.

Installation sur le client

Il suffit d’installer le paquet sshfs

sudo apt install -y sshfs

• Vous devrez veiller à ce que les utilisateurs potentiels de sshfs fassent bien partie du groupe fuse.
• Il est probable, surtout si vous utilisez l’authentification ssh par certificat (ce qui est le principal intérêt de sshfs), que vous deviez redémarrer la machine…

Vous obtiendrez l’erreur « failed to open /dev/fuse: Permission denied » si les points précédents ne sont pas vérifiés.

Monter un répertoire avec sshfs

En partant du principe que vous pouvez vous connecter en ssh sur la machine serveur, tout ce passe côté client.

Comme pour tous point de montage, vous devez avoir un répertoire vide qui « recevra » le dossier que vous souhaitez monter. Par exemple :

cd "$( xdg-user-dir DOCUMENTS )" # Version plus portable de : cd ~/Documents
mkdir mon_point_de_montage_sshfs

Vous pouvez alors utiliser les commandes suivantes :

• sshfs [user@]host:[dir] mountpoint [options] qui s’appuie directement sur FUSE,
• mount.sshfs [user@]host:[dir] mountpoint [options] qui permet de retrouver la syntaxe de mount,
• et enfin, la commande mount : mount -v -t sshfs [user@]host:[dir] mountpoint [options]

La syntaxe utilisant sshfs est largement documentée, mais je préfère rester sur la syntaxe de mount puisque l’idée est d’unifier la gestion des fichiers.

Quelques spécificités de sshfs

Avec sshfs on n’a pas la notion de création de partage, il est possible de monter n’importe quel dossier accessible par l’utilisateur et se fait relativement à cet utilisateur.

ainsi :

mount -v -t sshfs pi@192.168.1.102: mon_point_de_montage_sshfs

Montera le dossier $HOME de l’utilisateur pi sur la machine 192.168.1.102 dans le dossier local mon_point_de_montage_sshfs

Pour démonter, utiliser simplement :

umount mon_point_de_montage_sshfs # Implique d’être dans le même dossier que pour la commande mount

Si c’est l’écriture minimale, je vous décourage, en dehors d’un usage très spécifique, l’utilisation relative aussi bien sur l’ordinateur distant, mais plus encore sur l’ordinateur local.

Voici dont écriture, permettant de mieux contrôler ce que vous faites :

realpath mon_point_de_montage_sshfs

realpath "$( realpath "$( xdg-user-dir DOCUMENTS )/mon_point_de_montage_sshfs" )"

mount -v -t sshfs pi@192.168.1.102:/home/pi /home/user/Documents/mon_point_de_montage_sshfs

umount /home/user/Documents/mon_point_de_montage_sshfs

Options de sshhf

• idmap=XXX – Permet de gérer la transformation des UID/GID distants vers les valeurs locales.

Les valeurs possibles sont :

* `none` – pas de traduction de l’espace ID (par défaut).
* `user` – mapper l’UID/GID de l’utilisateur distant à l’UID/GID de l’utilisateur de montage.
* `file` – traduire les UID/GID en fonction du contenu de --uidfile et --gidfile.

En cas de doute, l’option idmap=user est probablement ce que vous souhaitez.

Options liées à l’optimisation de sshhf

Je trouve les performances de sshfs très correctes, j'ai testé la configuration ci-dessus, pas assez finement cependant pour avoir un avis définitif, mais je ne suis pas près ni à sacrifier la sécurité de mes machines, ni utilisé des options qui me semble être inadaptées (voire dangereuses ou contre-productives).
J’ai pris le temps de détailler ce que font ces options (ce qui n’est généralement pas présent dans les articles qui parlent d’optimisation) afin de faire votre choix.

• Conseils trouvés autour de l’optimisation

  De nombreuses couches sont impliquées dans sshfs, les options s’adressent donc à des couches différentes, je précise les options préconisées pour l’optimisation, ce qu’elles font et à quelle couche elles s’adressent.

  En fonction des machines concernées (disponibilité du CPU, RAM…) vous pouvez envisager les optimisations suivantes :

  Option	Traitée par	Commentaire
  Ciphers=arcfour	ssh	❓ Attention ce protocole est maintenant considéré comme peu sur, les préconisations sont plutôt de désactiver cela vos machines.
  Compression=no	ssh	👍 Suivant le type de données transportées compresser peut ralentir plus que gagner du temps.
  ServerAliveCountMax=3	ssh	❔ Pas d’avis, à creuser
  ServerAliveInterval=15	ssh	❔ Pas d’avis, à creuser
  cache=yes	???	❔ À creuser
  kernel_cache	fuse	👎 Cette option désactive le vidage du cache du contenu du fichier à chaque ouverture. Cela ne devrait être activé que sur les systèmes de fichiers, où les données du fichier ne sont jamais modifiées de manière externe (pas via le système de fichiers FUSE monté). Ainsi, il n'est pas adapté aux systèmes de fichiers réseau et aux autres systèmes de fichiers "intermédiaires".
  large_read	???	❔ À creuser
  reconnect	sshfs	👍 Relance la connexion au serveur si nécessaire.
  workaround=all	sshfs	👎 Voir ci-dessous, je suis très étonné de ce choix, cela ne concerne pas l’optimisation à mon sens, et ne devrait pas être utilisé sans de bonnes raisons.

  -o workaround=LIST – liste de solutions de contournement séparées par deux-points :
  * none – 👍 Aucune solution de contournement activée
  * [no]rename – 👎 Émulez l’écrasement d’un fichier existant en le supprimant et en le renommant. (par défaut : désactivé)
  * [no]renamexdev – ❔ Faire échouer le changement de nom avec EXDEV au lieu de l'EPERM par défaut pour permettre le déplacement de fichiers sur des systèmes de fichiers distants. (par défaut : désactivé)
  * [no]truncate – 👎 Contournez les serveurs qui ne prennent pas en charge la troncation en copiant l’intégralité du fichier, en le tronquant localement et en le renvoyant. (par défaut : désactivé)
  * [no]buflimit – 👍 Corrige un bogue de remplissage de tampon (« buffer fillup ») dans le serveur. (par défaut : désactivé)
  * [no]fstat – 👎 Contournez les serveurs défectueux qui ne prennent pas en charge fstat() en utilisant stat() à la place. (par défaut : désactivé)
  * [no]createmode – 👎 Contournez les serveurs cassés qui produisent une erreur lors du passage d’un mode non nul à créer, en passant toujours un mode de 0. (par défaut : désactivé)

  sshfs -o cache=yes -o large_read -o Compression=no -o ServerAliveCountMax=3 -o ServerAliveInterval=15 -o reconnect remoteuser@server:/remote/directory/ /media/mountpoint
  

les liens symboliques

Les liens symboliques ("symlink"), comme les liens durs ("hardlink") ne sont pas un problème pour sshfs, sauf dans un cas : si vous souhaitez monter dossier qui est en fait un lien symbolique.
C’est le cas des points de montage samba sur les NAS QNAP par exemple.

Pour éviter d’avoir une erreur, vous devez aller au delà du lien et c’est fort simple, il suffit d’ajouter un / final.

Au lieu d’utiliser :

mount -v -t sshfs admin@192.168.1.121:/share/photos /media/sshfs-username/photos

Utiliser :

mount -v -t sshfs admin@192.168.1.121:/share/photos/ /media/sshfs-username/photos

Astuce

Par convention les points de montage se font dessous le répertoire /media cependant, en tant qu’utilisateur, vous ne pouvez pas écrire dans ce dossier.
Je vous propose donc de créer un dossier sous /media que vous donnerez à votre utilisateur, comme suit :

sudo mkdir -vp "/media/sshfs-${USER}"                 # Création du répertoire en root
sudo chown "${USER}:${GROUP}" "/media/sshfs-${USER}"  # Transfert des droits vers l’utilisateur
chmod 700 "/media/sshfs-${USER}"                      # On donne tous les droits à l’utilisateur, et on enlève les droits aux autres.

Maintenant vous pouvez créer le dossier pour le point de montage sans les droits root.

mkdir -vp "/media/sshfs-${USER}/photos"

Que vous utiliser par exemple :

mount -v -t "sshfs admin@192.168.1.121:/share/photos/" "/media/sshfs-${USER}/photos"

La configuration de /etc/fstab

Si vous souhaitez mettre la configuration dans /etc/fstab, voici la syntaxe à utiliser :

user@machine:/répertoire/dossier_distant/   /media/sshfs-username/dossier_local    fuse.sshfs  port=22,user,noauto,noatime     0 0

Liens

• sshfs breaks symlinks from SFTP server,
• Odds and Ends: Optimizing SSHFS, moving files into subdirectories, and getting placeholder images,
• NAS Performance: NFS vs. SMB vs. SSHFS,
• Enable arcfour and Other Fast Ciphers on Recent Versions of OpenSSH
• Mount remote directory using SSH,
• How To Use SSHFS to Mount Remote File Systems Over SSH,
• Documentation Ubuntu en français :
  • Sur le Partage « de fichier »,
  • Sur le protocole sshfs.
• Page Wikipédia de FUSE,
• Documentation ArchLinux :
  • SSHFS.

ᦿ