sshfs - monter un répertoire distant à travers SSH

Introduction

Le SSH c’est bien, ça nous permet d’avoir un terminal distant, mais parfois on a besoin de travailler depuis notre poste de travail directement sur des fichiers. Et là, c’est plus compliqué : certains utilisent scp pour rapatrier les fichiers, les éditer puis les renvoyer. D’autres passent par un montage réseau type NFS ou SMB, mais ces protocoles sont plutôt pensés pour le réseau local, et les exposer sur Internet est rarement une bonne idée. Reste le SFTP via un client graphique (FileZilla et compagnie), mais on perd le confort d’éditer les fichiers en place avec ses outils habituels.

C’est là qu’entre en jeu sshfs.

Qu’est-ce que sshfs ?

sshfs est un système de fichiers en espace utilisateur (basé sur FUSE) qui s’appuie sur le sous-système SFTP de SSH. Concrètement : si vous avez un accès SSH à une machine, vous pouvez monter n’importe quel répertoire distant dans votre arborescence locale, sans rien installer ni configurer côté serveur. Tout transite chiffré dans le tunnel SSH, l’authentification par clé fonctionne comme d’habitude, et aucun port supplémentaire n’est à ouvrir.

Installation

sshfs est packagé partout, seul le client en a besoin :

# Debian / Ubuntu
sudo apt install sshfs

# RHEL / Rocky / Fedora
sudo dnf install fuse-sshfs

# Arch
sudo pacman -S sshfs

Utilisation de base

On crée un point de montage, puis on monte. La syntaxe ressemble volontairement à celle de scp :

mkdir -p ~/mnt/mon-serveur-distant
sshfs [email protected]:/ ~/mnt/mon-serveur-distant

Et c’est tout. Le contenu de / du serveur est maintenant accessible dans ~/mnt/mon-serveur-distant, avec votre éditeur, votre gestionnaire de fichiers, grep, rsync… comme s’il était local.

Si on omet le chemin distant après les deux-points, c’est le répertoire personnel de l’utilisateur qui est monté :

sshfs [email protected]: ~/mnt/mon-serveur-distant

Pour démonter :

umount ~/mnt/mon-serveur-distant
# ou, selon les systèmes
fusermount -u ~/mnt/mon-serveur-distant

Les options utiles

sshfs accepte les options classiques de mount via -o, ainsi que la plupart des options du client SSH. Quelques incontournables :

sshfs user@serveur:/var/www ~/mnt/mon-serveur-distant \
  -p 2222 \
  -o IdentityFile=~/.ssh/id_ed25519_admin \
  -o reconnect,ServerAliveInterval=15,ServerAliveCountMax=3 \
  -o follow_symlinks

-p 2222 : port SSH non standard, comme avec ssh.
IdentityFile : clé privée à utiliser. sshfs lit aussi votre ~/.ssh/config, donc un alias d’hôte déjà configuré fonctionne directement (sshfs monalias:/var/www ~/mnt/mon-serveur-distant).
reconnect + ServerAliveInterval : reconnexion automatique en cas de coupure réseau, indispensable sur une connexion instable. Sans ça, un montage cassé peut bloquer les processus qui y accèdent.
follow_symlinks : résout les liens symboliques côté serveur, sinon un lien pointant vers un chemin absolu distant sera cassé localement.

Deux autres options à connaître pour la gestion des droits :

allow_other : autorise les autres utilisateurs locaux à accéder au montage (nécessite user_allow_other décommenté dans /etc/fuse.conf).
idmap=user : fait correspondre l’UID/GID de l’utilisateur distant aux vôtres, pratique quand les identifiants numériques diffèrent entre les deux machines.

Montage automatique via fstab

Pour un montage persistant, on peut déclarer le tout dans /etc/fstab avec le type fuse.sshfs :

[email protected]:/var/www  /mnt/serveur  fuse.sshfs  noauto,x-systemd.automount,_netdev,reconnect,IdentityFile=/home/user/.ssh/id_ed25519,allow_other,ServerAliveInterval=15  0  0

Quelques précisions :

_netdev indique que le montage dépend du réseau, pour éviter que le boot ne tente de monter avant que le lien soit actif.
noauto,x-systemd.automount est la combinaison confortable : systemd monte le répertoire à la première tentative d’accès plutôt qu’au démarrage. Si le serveur est injoignable au boot, la machine ne reste pas bloquée.
L’authentification doit forcément se faire par clé sans passphrase interactive (ou via un agent), puisque personne ne sera là pour taper un mot de passe.

Performances

Soyons honnêtes : sshfs ne rivalisera jamais avec NFS sur un LAN. Chaque opération de fichier devient une requête SFTP dans un tunnel chiffré, la latence se paie cash, surtout sur les opérations portant sur beaucoup de petits fichiers (un git status sur un gros dépôt distant pique un peu). On peut néanmoins gratter pas mal :

sshfs user@serveur:/data ~/mnt/data \
  -o Ciphers=[email protected] \
  -o Compression=no \
  -o cache=yes,kernel_cache

Le choix du chiffrement joue sur le débit CPU ; chacha20-poly1305 ou aes128-ctr sont de bons candidats rapides.
Compression=no sur un lien rapide : compresser des données déjà compressées (images, archives) ne fait que brûler du CPU. À l’inverse, sur une liaison lente, Compression=yes peut aider.
Le cache côté noyau accélère sensiblement les relectures, au prix d’un risque de voir des données légèrement périmées si les fichiers changent côté serveur.

Les limites

sshfs est un excellent outil de confort pour l’administration et le développement, mais il faut connaître ses limites avant de l’utiliser en production :

Les verrous de fichiers (locks) sont mal ou pas supportés : à proscrire pour héberger une base de données ou tout applicatif qui en dépend.
Un montage dont la connexion est morte sans l’option reconnect peut geler les processus qui y accèdent, parfois jusqu’au kill -9.
Le projet sshfs d’origine n’est plus activement développé depuis 2022. Il reste packagé et fonctionnel dans toutes les distributions, mais c’est un point à garder en tête pour des usages critiques. Des alternatives comme rclone mount (qui sait aussi parler SFTP) ont pris le relais pour certains cas d’usage.

Conclusion

Pour le quotidien d’un sysadmin ou d’un développeur, sshfs est l’outil parfait du « j’ai juste besoin d’éditer trois fichiers sur ce serveur » : zéro configuration côté serveur, chiffré de bout en bout, et vos outils locaux fonctionnent tels quels. Pour du partage de fichiers permanent et performant, on restera sur NFS ou SMB en local, ou sur des solutions de synchronisation pour le distant. Mais dans sa niche, il est imbattable.