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

Pour monter automatiquement un répertoire SSHFS distant sous Debian, configurez l'authentification SSH non interactive et ajoutez une entrée SSHFS /etc/fstab. Avec systemd, vous pouvez soit vous connecter au démarrage, soit activer le montage automatique au démarrage et vous connecter lors du premier accès au répertoire. Cette seconde approche est utile lorsque le serveur distant ou le réseau peut être indisponible au démarrage.

Cette documentation utilise celle de Debian 13 « trixie », mise à jour le 9 octobre 2026, notamment celle relative à SSHFS 3.7.3 et systemd 257. Les commandes présentées sont des exemples de configuration et non des résultats de tests. Veuillez consulter la documentation installée si vous utilisez une autre version.

Choisissez le moment où la connexion SSHFS doit démarrer.

L'exemple principal utilise un montage à la demande. Cette distinction est importante : un montage automatique actif ne signifie pas qu'une connexion SSHFS existe déjà. Consultez le manuel de montage automatique systemd de Debian pour connaître la relation entre le montage automatique et son unité de montage correspondante.

Avant de commencer

• Le client Debian utilise systemd et vous disposez d'un accès sudo.
• Le compte distant prend en charge le protocole SFTP et peut accéder au répertoire prévu.
• Le client peut accéder à l'hôte distant, y compris à tout VPN ou serveur de rebond requis.
• Vous disposez d'un moyen de vérifier l'empreinte de la clé hôte SSH du serveur distant.
• Le point de montage local est vide et ne constitue pas un répertoire système critique.

Remplacez files@storage.example.net:/srv/datapar votre nom d'utilisateur distant, votre nom d'hôte et votre répertoire. Le nom d'hôte est un exemple. Le point de montage local est/mnt/remote ; la clé dédiée est /root/.ssh/sshfs_boot.

Il s'agit d'un montage système géré par l'administrateur. Il s'exécute localement en tant que root, mais se connecte au serveur distant en tant qu'utilisateur standard files, et non en tant que root distant. La documentation du projet SSHFS recommande généralement d'exécuter les montages interactifs ordinaires en tant qu'utilisateur normal. Un montage système au démarrage nécessite une gestion rigoureuse des informations d'identification et des accès.

1. Installez les packages clients

sudo apt update
sudo apt install sshfs openssh-client
sshfs --version
systemctl --version

Installez SSHFS sur le client Debian. Le système distant doit disposer d'un service SFTP fonctionnel ; l'installation de SSHFS n'est pas nécessaire pour le simple partage de fichiers. En cas d'échec de l'installation du paquet, résolvez le problème de dépôt ou de connectivité avant de modifier la configuration de démarrage.

2. Préparez le point de montage et la clé dédiée.

sudo install -d -m 0700 /root/.ssh
sudo mkdir -p /mnt/remote
sudo ssh-keygen -t ed25519 -f /root/.ssh/sshfs_boot -N ''
sudo chmod 0600 /root/.ssh/sshfs_boot

Ne remplacez pas une clé existante à cet emplacement. Choisissez un autre nom si nécessaire et utilisez-le systématiquement par la suite. L'absence de phrase secrète est intentionnelle dans cet exemple de fonctionnement sans surveillance : personne n'est disponible pour déverrouiller la clé au démarrage. Protégez le client et n'accordez au compte distant que les autorisations d'accès au répertoire dont il a besoin. Si votre politique exige des clés chiffrées, mettez en place un mécanisme de déverrouillage sans surveillance géré.

Les options de génération de clés sont documentées dans le manuel ssh-keygen de Debian . Une clé déverrouillée dans votre agent SSH de bureau n'est pas automatiquement disponible pour le montage système.

3. Autoriser la clé et vérifier le SFTP sans surveillance

sudo ssh-copy-id -i /root/.ssh/sshfs_boot.pub files@storage.example.net

Lors de cette connexion d'établissement, comparez l'empreinte de la clé hôte affichée avec une valeur fournie par l'administrateur du serveur via un canal de confiance avant de l'accepter. La commande s'exécute en tant que superutilisateur local (root), la clé hôte est donc stockée dans les fichiers SSH de root. Si l'authentification par mot de passe est désactivée sur le serveur, demandez à l'administrateur d'installer la clé publique.

Ensuite, testez le protocole SFTP avec le même fichier d'identité et de clé d'hôte que celui utilisé par le montage de démarrage :

sudo sftp -i /root/.ssh/sshfs_boot \
  -o IdentitiesOnly=yes -o BatchMode=yes \
  -o StrictHostKeyChecking=yes \
  -o UserKnownHostsFile=/root/.ssh/known_hosts \
  files@storage.example.net

À l'invite SFTP, utilisez `ssh` ls /srv/data, puis `ssh` bye. Cela doit fonctionner sans mot de passe ni confirmation. BatchMode=yes`ssh` empêche l'authentification interactive ; la configuration explicite de la clé d'hôte préserve la vérification. Ces options sont définies dans le manuel de configuration du client OpenSSH .

Pour un port non standard, utilisez les options -p 2222`ssh-copy-id`, -P 2222`sftp` et port=2222`SSHFS`. Si un serveur intermédiaire est nécessaire, configurez et testez également cette route dans le contexte SSH de l'utilisateur root.

4. Prouver que le montage manuel fonctionne

sudo sshfs files@storage.example.net:/srv/data /mnt/remote \
  -o IdentityFile=/root/.ssh/sshfs_boot,IdentitiesOnly=yes,BatchMode=yes \
  -o StrictHostKeyChecking=yes,UserKnownHostsFile=/root/.ssh/known_hosts
sudo ls /mnt/remote
sudo umount /mnt/remote

Vérifiez que le répertoire distant correspond bien au répertoire souhaité. Cet exemple n'autorise initialement l'accès qu'à l'utilisateur root (propriétaire du montage local) ; utilisez donc sudo pour effectuer la vérification. Terminez en démontant le montage avant de lancer la configuration gérée par systemd. Fermez les shells et les applications utilisant ce répertoire s'il est occupé.

SSHFS utilise les permissions du compte distant. Être root sur le client ne confère pas de permissions supplémentaires sur le serveur. Corrigez les erreurs d'authentification, de SFTP ou de chemin d'accès distant ici avant de rendre la configuration permanente.

5. Ajoutez l'entrée fstab persistante

sudo cp -a /etc/fstab /etc/fstab.sshfs-backup
sudoedit /etc/fstab

Choisissez un autre nom de fichier de sauvegarde si celui-ci existe déjà. Ajoutez le texte suivant sur une seule ligne , en remplaçant le serveur et le chemin d'accès d'exemple :

files@storage.example.net:/srv/data /mnt/remote sshfs _netdev,nofail,x-systemd.automount,x-systemd.mount-timeout=30s,IdentityFile=/root/.ssh/sshfs_boot,IdentitiesOnly=yes,BatchMode=yes,StrictHostKeyChecking=yes,UserKnownHostsFile=/root/.ssh/known_hosts,ConnectTimeout=10,reconnect,ServerAliveInterval=15,ServerAliveCountMax=3 0 0

Le manuel SSHFS de Debian spécifie sshfsle type de système de fichiers fstab et l'accepte fuse.sshfspour des raisons de compatibilité. Les derniers champs désactivent la planification des vidages et des vérifications du système de fichiers pour cette entrée. Consultez la documentation de référence du format fstab si les chemins contiennent des espaces.

Les options spécifiques à systemd sont documentées dans le manuel de montage systemd de Debian . Le délai d'expiration du montage n'impose pas de limite à chaque opération de fichier ultérieure.

6. Rechargez systemd et activez le montage automatique

sudo findmnt --verify --verbose
sudo systemctl daemon-reload
sudo systemctl start mnt-remote.automount
systemctl status mnt-remote.automount
sudo ls /mnt/remote
findmnt -t fuse.sshfs

Veuillez consulter les messages de vérification avant de continuer. Le manuel de findmnt décrit la vérification du fichier fstab ; celle-ci contrôle la configuration et non la validité des informations d'identification distantes. L'accès au répertoire effectue un test de connexion distinct.

Les noms d'unités ci-dessus correspondent à /mnt/remote. Pour un autre chemin, déterminez le nom de montage avec systemd-escape --path --suffix=mount /your/path. Les unités générées à partir de fstab ne nécessitent pas de systemctl enablecommande supplémentaire.

Si vous souhaitez une tentative de connexion au démarrage, supprimez x-systemd.automountl'entrée correspondante. Après avoir libéré les utilisateurs du répertoire, arrêtez son montage automatique et ses unités de montage, rechargez systemd et démarrez l'unité de montage correspondante. Conservez cette entrée nofailsi le stockage doit rester optionnel.

7. Vérifiez le comportement après un redémarrage

Redémarrez à un moment opportun pour la maintenance. Avec la configuration à la demande, vérifiez d'abord le montage automatique, puis accédez au répertoire :

systemctl status mnt-remote.automount
sudo ls /mnt/remote
systemctl status mnt-remote.mount
findmnt -t fuse.sshfs

Les signes attendus sont un montage automatique actif au démarrage et un montage SSHFS effectif après accès. Une autofsentrée SSHFS seule ne prouve pas que les fichiers distants sont connectés. Vérifiez l'existence d'un fichier ou d'un répertoire distant connu, et non pas simplement celle du dossier de montage local.

Si une application nécessite cet espace de stockage avant de démarrer, ajoutez un module complémentaire à son service contenant :

[Unit]
RequiresMountsFor=/mnt/remote

Cette dépendance, documentée dans systemd.unit , charge et organise les montages nécessaires. Rechargez systemd et testez le démarrage de l'application séparément. L'application requiert également les autorisations d'accès locales appropriées.

8. Dépannage par type de panne

sudo journalctl -b -u mnt-remote.mount
sudo journalctl -b -u mnt-remote.automount

network-online.targetIl s'agit d'un point de synchronisation au démarrage, et non d'une garantie de disponibilité d'un serveur ou d'un VPN particulier. La documentation de systemd network-online décrit cette limitation.

Pour un accès intentionnel par un utilisateur local, envisagez d'ajouter ` allow_other,default_permissions,uid=1000,gid=1000<UID>`, en remplaçant `<UID>` par les identifiants locaux réels. Cela autorise l'accès au-delà du propriétaire du point de montage, tout en maintenant les vérifications des permissions du noyau. Les options `UID`/`GID` modifient la propriété affichée, et non la propriété côté serveur. Les points de montage racine ne nécessitent pas `<UID>` user_allow_otherdans `fuse.conf` ; cette règle permet aux points de montage non racine de demander un accès plus étendu. Consultez le manuel des permissions FUSE . Effectuez un nouveau test en tant qu'utilisateur de l'application après avoir modifié ces options.

Après avoir résolu le problème sous-jacent, effacez l'état de montage défaillant et réessayez l'accès :

sudo systemctl reset-failed mnt-remote.mount
sudo ls /mnt/remote

La reconnexion n'est pas une solution de récupération transparente pour toutes les applications : les fichiers précédemment ouverts peuvent échouer et nécessiter une réouverture. Les écritures interrompues peuvent entraîner une perte de données. Si votre charge de travail exige une meilleure tolérance aux pannes, optez pour une autre solution de stockage.

Liste de contrôle opérationnelle et restauration

• Le protocole SFTP sans surveillance fonctionne en utilisant l'identité de démarrage exacte.
• La clé hôte est vérifiée et enregistrée dans le fichier prévu.
• L'entrée fstab est analysée et ne contient aucun mot de passe ni contenu de clé privée.
• L'accès après redémarrage affiche la liste des serveurs distants attendue.
• L'utilisateur ou le service local concerné peut lire les fichiers requis.
• Vous comprenez comment l'application gère l'espace de stockage indisponible.

Pour désactiver la configuration, arrêtez les applications utilisant le répertoire, supprimez uniquement cette entrée du fichier fstab, puis exécutez mnt-remote.automountla commande appropriée. Conservez les autres entrées du fichier fstab. La suppression de la configuration de montage ne supprime pas les fichiers distants et ne révoque pas la clé d'autorisation distante.mnt-remote.mountsudo systemctl daemon-reload