Comment monter automatiquement un répertoire SSHFS distant au démarrage sous Debian

Vous configurez un montage SSHFS, vérifiez son bon fonctionnement, redémarrez Debian, et soudain, le répertoire distant est de nouveau vide. La commande manuelle a fonctionné car vous étiez connecté, le réseau était déjà en ligne et SSH pouvait poser des questions si nécessaire (mot de passe ou confirmation de clé d'hôte). Les montages au démarrage ne bénéficient pas de ces facilités.

La solution fiable consiste à désactiver l'authentification SSH, à créer une /etc/fstabentrée persistante et à indiquer à systemd que le système de fichiers dépend du réseau. Ce guide commence par la configuration fonctionnelle la plus simple, puis ajoute des options pour les réseaux lents et les interruptions de session SSH. Les exemples utilisent `/var/lib` user@server.example.com:/srv/datacomme répertoire distant et `/var/lib` /mnt/remotecomme point de montage local.

La page des paquets Debian indique actuellement SSHFS 3.7.3 pour Debian 12 (Bookworm). SSHFS utilise le sous-système SFTP fourni par SSH. Consultez la page des paquets SSHFS pour Debian et le manuel SSHFS officiel . Les révisions des paquets varient selon les versions de Debian, mais la méthode de montage au démarrage décrite ci-dessous est basée sur le comportement standard de fstab et systemd.

Pourquoi un montage SSHFS fonctionne-t-il manuellement mais échoue-t-il au démarrage ?

La plupart des échecs sont dus à trois causes principales. Premièrement, SSH peut encore exiger un mot de passe, une phrase secrète ou une confirmation de clé d'hôte lors de la première connexion. Un processus de démarrage ne dispose pas de terminal pour répondre à ces demandes. Deuxièmement, le montage peut démarrer avant que le réseau ou le DNS ne soient pleinement opérationnels. Troisièmement, une connexion SSH active depuis longtemps peut devenir obsolète après une interruption réseau.

La documentation systemd de Debian explique que cette _netdevoption force le traitement d'un point de montage comme un point de montage réseau. Les points de montage réseau sont placés après les points de montage réseau network-online.target. La même documentation indique que /etc/fstables entrées sont converties en unités de montage systemd natives au démarrage. Voir systemd.mount(5) dans la documentation Debian .

1. Installez SSHFS et créez le point de montage

Installez le client SSHFS fourni et créez le répertoire local qui exposera les fichiers distants :

sudo apt update
sudo apt install sshfs
sudo mkdir -p /mnt/remote

SSHFS est basé sur FUSE, l'interface de gestion de fichiers Linux en espace utilisateur. Sous Debian 12, ce sshfspaquet dépend de FUSE 3 et du client OpenSSH.

2. Configurez une authentification SSH qui puisse s'exécuter sans invite.

Pour un montage système lancé par systemd, l'utilisation d'une clé dédiée appartenant à root est simple car l'assistant de montage s'exécute en tant que root. Générez-en une sans phrase secrète uniquement si la machine elle-même est de confiance et que la clé est exclusivement réservée à cet usage.

sudo ssh-keygen -t ed25519 -f /root/.ssh/sshfs_remote
sudo ssh-copy-id -i /root/.ssh/sshfs_remote.pub user@server.example.com

La deuxième commande demande normalement une seule fois le mot de passe du compte distant. Ensuite, testez l'identité exacte de manière non interactive :

sudo ssh -i /root/.ssh/sshfs_remote -o BatchMode=yes user@server.example.com true

Si cette commande s'exécute correctement sans message d'erreur, l'authentification est prête pour le démarrage. Si le système demande de confirmer l'empreinte du serveur, connectez-vous une fois en tant que superutilisateur (root), vérifiez l'empreinte auprès d'une source fiable et acceptez-la. Ne contournez pas les erreurs de clé d'hôte en désactivant la vérification de l'hôte.

La documentation OpenSSH BatchMode=yesest spécifiquement conçue pour les scripts et les tâches par lots, car elle désactive les invites de mot de passe et de confirmation. Les clés d'hôte sont vérifiées par rapport au fichier de l'utilisateur known_hosts. Consultez le manuel Debian ssh(1) et ssh_config(5) .

3. Vérifiez manuellement le montage SSHFS avant de modifier le fichier fstab.

Ne tentez pas de déboguer l'ordre de démarrage tant que la commande SSHFS de base ne fonctionne pas. Montez le répertoire une seule fois avec la même clé :

sudo sshfs user@server.example.com:/srv/data /mnt/remote   -o IdentityFile=/root/.ssh/sshfs_remote   -o reconnect   -o ServerAliveInterval=15   -o ServerAliveCountMax=3

Vérifiez que vous pouvez lister les fichiers distants, puis démontez le système de fichiers avant de tester fstab :

ls -la /mnt/remote
sudo fusermount3 -u /mnt/remote

Le manuel SSHFS d'origine recommande reconnectde rétablir les connexions interrompues. Il explique également que ServerAliveIntervalcela peut éviter un montage apparemment bloqué lorsqu'une connexion SSH inactive est silencieusement interrompue. Avec un intervalle de 15 secondes et le nombre par défaut de trois requêtes sans réponse d'OpenSSH, une connexion interrompue est détectée en environ 45 secondes ; ce nombre est indiqué explicitement afin de rendre le comportement plus clair.

4. Ajoutez une entrée SSHFS persistante au fichier /etc/fstab

Sauvegardez le fichier avant de le modifier :

sudo cp /etc/fstab /etc/fstab.backup
sudo nano /etc/fstab

Ajoutez une ligne :

user@server.example.com:/srv/data /mnt/remote fuse.sshfs _netdev,IdentityFile=/root/.ssh/sshfs_remote,BatchMode=yes,reconnect,ServerAliveInterval=15,ServerAliveCountMax=3,default_permissions 0 0

Le fuse.sshfssous-type est reconnu par les outils de montage de Debian. Le manuel SSHFS d'origine le documente également sshfscomme un type de système de fichiers fstab et fournit des notes fuse.sshfsde compatibilité. Le manuel fstab(5) de Debian décrit les six champs fstab et recommande une notation de sous-type de système de fichiers telle que : fuse.sshfs.

5. Testez l'entrée fstab avant de redémarrer.

Il est beaucoup plus facile de corriger une faute de frappe /etc/fstabavant un redémarrage. Demandez à systemd de recharger les unités de montage générées, puis testez l'entrée :

sudo systemctl daemon-reload
sudo mount -a
findmnt -T /mnt/remote
ls -la /mnt/remote

Si mount -ala commande ne renvoie aucune erreur et findmntaffiche un message d'erreur fuse.sshfs, la syntaxe fstab est acceptée et le système de fichiers est monté. Le manuel mount(8) de Debian confirme que mount -acette commande monte les systèmes de fichiers fstab à l'exception des entrées marquées comme telles noauto.

Et si le réseau n'est pas prêt assez rapidement ?

_netdevsystemd obtient ainsi une sémantique d'ordonnancement correcte, mais network-online.targetsa précision dépend du service de gestion réseau qui la fournit. Le Wi-Fi, les VPN, les délais DHCP et DNS, ainsi que les configurations réseau inhabituelles peuvent rendre un montage de démarrage immédiat peu fiable.

Dans ce cas, utilisez le montage automatique systemd afin que le processus de démarrage crée un point de montage automatique et établisse la connexion SSHFS uniquement lors du premier accès /mnt/remote. Ajoutez ceci x-systemd.automountaux options :

user@server.example.com:/srv/data /mnt/remote fuse.sshfs _netdev,x-systemd.automount,IdentityFile=/root/.ssh/sshfs_remote,BatchMode=yes,reconnect,ServerAliveInterval=15,ServerAliveCountMax=3,default_permissions 0 0

Cette solution est souvent préférable pour les ordinateurs portables, les systèmes Wi-Fi ou les serveurs où l'hôte distant peut être occasionnellement indisponible. Elle modifie légèrement le fonctionnement : le montage automatique est préparé au démarrage, mais la connexion SSH est établie lors du premier accès. Si une application nécessite impérativement la connexion au répertoire distant avant son lancement, conservez le montage réseau classique et faites en sorte que l'unité systemd de cette application dépende plutôt de l'unité de montage.

Avez-vous besoin de allow_other ?

Par défaut, un montage FUSE n'est accessible qu'avec les permissions associées au contexte de montage. La documentation SSHFS allow_otherexplique comment autoriser l'accès à d'autres utilisateurs locaux. N'autorisez cet accès que si un service ou un autre compte en a réellement besoin.

Si vous l'utilisez allow_other, consultez /etc/fuse.confd'abord les implications de sécurité de FUSE. L'associer à un autre logiciel default_permissionsest généralement approprié afin de ne pas négliger les vérifications des permissions Unix locales. Le compte SSH distant détermine en fin de compte les opérations autorisées sur le serveur.

Dépannage des échecs SSHFS au démarrage

Le point de montage attend un mot de passe

Répétez exactement le test non interactif sudo ssh ... -o BatchMode=yes. S'il échoue, corrigez l'authentification par clé publique avant de modifier systemd. Une clé protégée par une phrase secrète nécessite également un agent ou un autre mécanisme de sécurité au démarrage ; un simple montage fstab ne peut pas saisir la phrase secrète automatiquement.

La vérification de la clé hôte a échoué

Ne pas appliquer StrictHostKeyChecking=nocette solution de manière systématique. Vérifiez si le serveur a été reconstruit ou si sa clé d'hôte a été légitimement modifiée. La vérification de la clé d'hôte SSH est une mesure de sécurité contre l'usurpation d'identité et les attaques de type « homme du milieu ».

Le montage fonctionne après la connexion, mais pas pendant le démarrage.

Vérifiez le nom de l'unité générée et son journal. Pour /mnt/remote, systemd échappe généralement le chemin vers mnt-remote.mount:

systemctl status mnt-remote.mount
journalctl -b -u mnt-remote.mount

Si vous avez ajouté x-systemd.automount, vérifiez également :

systemctl status mnt-remote.automount

L'accès se bloque après la disparition du serveur ou du réseau.

Les fonctions Keep reconnectet SSH keepalives sont activées. La documentation SSHFS d'origine indique que les opérations sur le système de fichiers peuvent se bloquer indéfiniment lorsqu'une interruption de connexion n'est pas détectée. Les keepalives limitent la détection des pannes, mais toute opération d'E/S en cours au moment de la coupure de la connexion peut toujours échouer et nécessiter une nouvelle tentative de la part de l'application.

Comment vérifier que le montage survit bien à un redémarrage

Une fois mount -al'opération réussie, redémarrez la machine :

sudo reboot

Après la reconnexion, effectuez les vérifications suivantes :

findmnt -T /mnt/remote
systemctl is-active mnt-remote.mount
ls -la /mnt/remote

Si vous avez choisi cette option x-systemd.automount, l'unité de montage peut être inactive jusqu'au premier accès. Vérifiez d'abord le montage automatique, puis déclenchez-le avecls :

systemctl is-active mnt-remote.automount
ls -la /mnt/remote
findmnt -T /mnt/remote

Une configuration réussie présente quatre propriétés observables : l’authentification SSH s’effectue sans intervention, l’entrée fstab est valide mount -a, systemd reconnaît le point de montage comme dépendant du réseau et les fichiers distants sont accessibles après un redémarrage. Si l’une de ces vérifications échoue, il convient de résoudre directement le problème à cet endroit plutôt que d’ajouter des options de montage au hasard.