Ha de posseir la sessió d'usuari el muntatge SSHFS sobre VPN?

Muntar una carpeta compartida després que la VPN pugi implica dues identitats que és fàcil confondre: el component autoritzat a configurar la xarxa i el compte autoritzat a iniciar sessió al servidor de fitxers. Poques vegades són la mateixa. Un hook de VPN propietat de root és un mal lloc per iniciar el muntatge SSHFS d'un usuari d'escriptori, perquè no té ni l'agent de l'usuari ni la propietat de muntatge prevista. Encertar primer la propietat fa que el desencadenant sigui simple.

Dues identitats, dos permisos separats

El client de VPN necessita privilegis per canviar rutes i interfícies. El muntatge SSHFS necessita una identitat SSH que el servidor de fitxers accepti i un muntatge FUSE propietat del compte que llegirà els fitxers. Un sol script executat com a root satisfà el primer requisit i trenca silenciosament el segon.

Muntar com a root deixa els fitxers fora de la sessió d'escriptori i possiblement sense accés a l'agent que guarda la clau de l'usuari. El muntatge existeix, l'usuari no hi pot escriure i la fallada sembla un problema de permisos del servidor. Aquest diagnòstic erroni costa una tarda i un tiquet a l'equip d'emmagatzematge.

Decidiu quin compte posseeix el muntatge abans d'escriure cap automatització, perquè aquesta elecció determina on viu el desencadenant i a quines credencials pot arribar.

Primer establiu a mà un muntatge propietat de l'usuari

Partiu d'un usuari autenticat amb un punt de muntatge buit, un compte SSH autoritzat i un camí funcional cap al servidor a través del túnel. Un muntatge manual estableix la línia base que qualsevol automatització ha de reproduir.

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

Els noms són exemples, així que substituïu l'amfitrió i el camí d'exportació que el vostre servidor ofereix realment. Verifiqueu la clau de l'amfitrió mitjançant el procés aprovat en aquesta primera connexió. Tingueu en compte que la contrasenya del compte de VPN no és automàticament la credencial del compte d'emmagatzematge, i això és una causa habitual d'intents fallits.

Executeu-lo com a usuari normal amb un punt de muntatge propietat d'aquest usuari. Per defecte, només el compte que munta arriba als fitxers, i allow_other amplia aquesta frontera a cada usuari local. Això és una ampliació deliberada de l'accés, no una solució alternativa per a l'automatització.

Feu que el desencadenant actuï en el mateix context de sessió

Deixeu que la integració d'esdeveniments de VPN admesa demani executar una acció de la sessió d'usuari, en lloc de suposar que un callback privilegiat pot manllevar una credencial d'escriptori. Limiteu el desencadenant a l'identificador de connexió previst i no a qualsevol interfície que es digui tun0 per casualitat. Una regla de distribuïdor que coincideix amb la cosa equivocada s'activa a cada canvi de xarxa, inclosos els que no tenen res a veure amb aquest muntatge.

L'acció hauria de confirmar el nom d'amfitrió esperat, adonar-se d'un muntatge existent i fer un intent limitat. Un bucle d'enquesta que inicia un procés SSHFS nou cada pocs segons, o reintenta una petició de credencials mentre el servidor està caigut, converteix una interrupció curta en un munt de processos encallats. Limiteu l'intent amb un temps d'espera i un sol reintent.

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

La primera ordre dona l'identificador de connexió que el distribuïdor ha de coincidir. Les altres dues mostren si ja hi ha un intent en marxa, i aquesta és la comprovació que evita duplicats.

Un servei sense supervisió necessita les seves pròpies credencials aprovades i el seu propi mecanisme de verificació d'amfitrió en el seu propi context d'execució. No pot suposar que un agent gràfic estigui desbloquejat, i no hauria d'intentar desbloquejar-lo.

Planifiqueu la desconnexió abans de forçar la neteja

Per a una desconnexió planificada, acabeu les operacions de fitxers i desmunteu des del flux de treball del mateix usuari que munta. Apunteu al punt de muntatge i no al procés, i confirmeu el resultat abans d'informar d'èxit.

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

Desmunteu només el muntatge que ha creat aquest flux de treball. Si està ocupat, és una decisió de l'aplicació: una separació forçada que existeix per fer que un hook retorni èxit amaga la pèrdua de dades en lloc d'evitar-la.

La pèrdua inesperada es comporta diferentment. SSHFS documenta que una interrupció de xarxa pot bloquejar una operació del sistema de fitxers, i l'opció reconnect restaura el transport sense restaurar els handles: un fitxer obert abans de la reconnexió pot fallar a l'escriptura següent, i una escriptura interrompuda no es conserva. Aquesta distinció és la més important per als editors que mantenen un fitxer obert durant hores. Planifiqueu un pas de reobertura en lloc de suposar la recuperació.

Proveu el comportament amb fitxers d'un sol ús abans de confiar-hi. Un directori que reapareix després que el túnel torni no demostra que els handles anteriors o el treball no desat hagin sobreviscut.