La session utilisateur doit-elle posséder le montage SSHFS sur VPN ?

Monter un dossier partagé après la montée du VPN implique deux identités faciles à confondre : le composant autorisé à configurer le réseau et le compte autorisé à se connecter au serveur de fichiers. Elles sont rarement identiques. Un hook VPN appartenant à root est un mauvais point de départ pour le montage SSHFS d’un utilisateur de bureau, car il ne dispose ni de l’agent de l’utilisateur ni de la propriété de montage prévue. Régler d’abord la propriété rend le déclencheur simple.

Deux identités, deux permissions distinctes

Le client VPN a besoin de privilèges pour modifier les routes et les interfaces. Le montage SSHFS a besoin d’une identité SSH acceptée par le serveur de fichiers et d’un montage FUSE appartenant au compte qui lira les fichiers. Un seul script exécuté en root satisfait la première exigence et casse silencieusement la seconde.

Monter en root laisse les fichiers hors de la session de bureau et peut-être sans accès à l’agent qui détient la clé de l’utilisateur. Le montage existe, l’utilisateur ne peut pas écrire à travers, et la panne ressemble à un problème de permissions côté serveur. Ce diagnostic erroné coûte un après-midi et un ticket à l’équipe de stockage.

Décidez quel compte possède le montage avant d’écrire la moindre automatisation, car ce choix détermine où vit le déclencheur et quels identifiants il peut atteindre.

Établissez d’abord à la main un montage appartenant à l’utilisateur

Partez d’un utilisateur connecté avec un point de montage vide, un compte SSH autorisé et un chemin fonctionnel vers le serveur via le tunnel. Un montage manuel établit la base que toute automatisation doit reproduire.

mkdir -p "$HOME/mnt/team"
sshfs [email protected]:/exports/team "$HOME/mnt/team"
mount | grep sshfs

Les noms sont des exemples, remplacez donc l’hôte et le chemin d’exportation que votre serveur propose réellement. Vérifiez la clé d’hôte via le processus approuvé lors de cette première connexion. Notez que le mot de passe du compte VPN n’est pas automatiquement l’identifiant du compte de stockage, et c’est une cause fréquente d’échecs.

Exécutez-le en tant qu’utilisateur normal avec un point de montage appartenant à cet utilisateur. Par défaut, seul le compte qui monte atteint les fichiers, et allow_other étend cette frontière à chaque utilisateur local. C’est un élargissement délibéré de l’accès, pas un contournement pour l’automatisation.

Faites agir le déclencheur dans le même contexte de session

Laissez l’intégration d’événements VPN prise en charge demander l’exécution d’une action de session utilisateur, au lieu de supposer qu’un callback privilégié peut emprunter un identifiant de bureau. Limitez le déclencheur à l’identifiant de connexion prévu plutôt qu’à toute interface qui s’appelle tun0 par hasard. Une règle de répartiteur qui correspond à la mauvaise chose se déclenche à chaque changement de réseau, y compris ceux qui n’ont rien à voir avec ce montage.

L’action doit confirmer le nom d’hôte attendu, remarquer un montage existant et faire une tentative bornée. Une boucle d’interrogation qui lance un nouveau processus SSHFS toutes les quelques secondes, ou réessaie une demande d’identifiants pendant que le serveur est indisponible, transforme une courte panne en un tas de processus bloqués. Bornez la tentative avec un délai d’attente et une seule nouvelle tentative.

nmcli -g UUID connection show --active
systemctl --user list-units 'sshfs*'
pgrep -a sshfs

La première commande donne l’identifiant de connexion que le répartiteur doit faire correspondre. Les deux autres montrent si une tentative est déjà en cours, et c’est la vérification qui évite les doublons.

Un service sans surveillance a besoin de ses propres identifiants approuvés et de sa propre vérification d’hôte dans son propre contexte d’exécution. Il ne peut pas supposer qu’un agent graphique est déverrouillé, et il ne devrait pas essayer d’en déverrouiller un.

Planifiez la déconnexion avant de forcer le nettoyage

Pour une déconnexion planifiée, terminez les opérations de fichiers et démontez depuis le flux de travail de l’utilisateur qui monte. Ciblez le point de montage plutôt que le processus, et confirmez le résultat avant d’annoncer un succès.

fusermount3 -u "$HOME/mnt/team"
mountpoint "$HOME/mnt/team"

Ne démontez que le montage créé par ce flux de travail. S’il est occupé, c’est une décision de l’application : un détachement forcé qui existe pour faire renvoyer un succès à un hook masque la perte de données au lieu de l’éviter.

Une perte inattendue se comporte différemment. SSHFS documente qu’une interruption réseau peut bloquer une opération de système de fichiers, et l’option reconnect restaure le transport sans restaurer les handles : un fichier ouvert avant la reconnexion peut échouer à l’écriture suivante, et une écriture interrompue n’est pas conservée. Cette distinction compte surtout pour les éditeurs qui gardent un fichier ouvert pendant des heures. Planifiez une étape de réouverture au lieu de supposer une récupération.

Testez le comportement avec des fichiers jetables avant de vous y fier. Un répertoire qui réapparaît après le retour du tunnel ne prouve pas que les handles précédents ou le travail non enregistré ont survécu.