How to Mount a Remote SSHFS Directory Automatically at Boot in Debian

To mount a remote SSHFS directory automatically in Debian, configure noninteractive SSH authentication and add an SSHFS entry to /etc/fstab. With systemd, you can either connect during boot or activate an automount at boot and connect when the directory is first accessed. The second approach is useful when the remote server or network may be unavailable during startup.

This reference uses Debian 13 “trixie” documentation reviewed on October 9, 2026, including SSHFS 3.7.3 and systemd 257 documentation. The commands are configuration examples, not results from a tested deployment. Check your installed manuals if you use another release.

Choose when the SSHFS connection should start

The main example uses an on-demand mount. The distinction matters: an active automount does not mean an SSHFS connection already exists. See Debian’s systemd automount manual for the relationship between the automount and its matching mount unit.

Before you start

• The Debian client uses systemd and you have sudo access.
• The remote account supports SFTP and can access the intended directory.
• The client can reach the remote host, including any required VPN or jump host.
• You have a way to verify the remote server’s SSH host-key fingerprint.
• The local mount point is empty and is not a critical system directory.

Replace files@storage.example.net:/srv/data with your remote username, hostname, and directory. The hostname is a placeholder. The local mount point is /mnt/remote; the dedicated key is /root/.ssh/sshfs_boot.

This is an administrator-managed system mount. It runs locally as root but logs into the remote server as files, not remote root. The SSHFS project documentation generally recommends running ordinary interactive mounts as a regular user. A system boot mount requires deliberate credential and access management.

1. Install the client packages

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

Install SSHFS on the Debian client. The remote system needs working SFTP service; it does not need an SSHFS installation just to serve files. If package installation fails, resolve the repository or connectivity issue before editing boot configuration.

2. Prepare the mount point and dedicated key

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 ordonne 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