La sessione utente deve possedere il mount SSHFS su VPN?

Montare una cartella condivisa dopo l’avvio della VPN coinvolge due identità facili da confondere: il componente autorizzato a configurare la rete e l’account autorizzato ad accedere al file server. Raramente sono la stessa. Un hook VPN di proprietà di root è un cattivo punto di partenza per il mount SSHFS di un utente desktop, perché non ha né l’agente dell’utente né la proprietà del mount prevista. Impostare prima correttamente la proprietà rende semplice il trigger.

Due identità, due permessi separati

Il client VPN ha bisogno di privilegi per cambiare route e interfacce. Il mount SSHFS ha bisogno di un’identità SSH accettata dal file server e di un mount FUSE di proprietà dell’account che leggerà i file. Un solo script eseguito come root soddisfa il primo requisito e rompe silenziosamente il secondo.

Montare come root lascia i file fuori dalla sessione desktop e forse senza accesso all’agente che custodisce la chiave dell’utente. Il mount esiste, l’utente non può scrivere attraverso di esso e l’errore sembra un problema di permessi lato server. Quella diagnosi errata costa un pomeriggio e un ticket al team di archiviazione.

Decidi quale account possiede il mount prima di scrivere qualsiasi automazione, perché questa scelta determina dove vive il trigger e quali credenziali può raggiungere.

Stabilisci prima manualmente un mount di proprietà dell’utente

Parti da un utente che ha effettuato l’accesso con un punto di mount vuoto, un account SSH autorizzato e un percorso funzionante verso il server attraverso il tunnel. Un mount manuale stabilisce la linea di base che qualsiasi automazione deve riprodurre.

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

I nomi sono esempi, quindi sostituisci l’host e il percorso di esportazione che il tuo server offre realmente. Verifica la chiave dell’host tramite il processo approvato su quella prima connessione. Nota che la password dell’account VPN non è automaticamente la credenziale dell’account di archiviazione, e questa è una causa comune di tentativi falliti.

Eseguilo come utente normale con un punto di mount di proprietà di quell’utente. Per impostazione predefinita solo l’account che monta raggiunge i file, e allow_other estende quel confine a ogni utente locale. È un ampliamento deliberato dell’accesso, non una scorciatoia per l’automazione.

Fai agire il trigger nello stesso contesto di sessione

Lascia che l’integrazione degli eventi VPN supportata chieda di eseguire un’azione della sessione utente, invece di supporre che un callback privilegiato possa prendere in prestito una credenziale desktop. Limita il trigger all’identificatore di connessione previsto anziché a qualsiasi interfaccia che si chiami tun0 per caso. Una regola del dispatcher che corrisponde alla cosa sbagliata scatta a ogni cambiamento di rete, inclusi quelli che non hanno nulla a che fare con questo mount.

L’azione dovrebbe confermare il nome host previsto, notare un mount esistente e fare un tentativo limitato. Un ciclo di polling che avvia un nuovo processo SSHFS ogni pochi secondi, o ripete una richiesta di credenziali mentre il server è inattivo, trasforma una breve interruzione in un mucchio di processi bloccati. Limita il tentativo con un timeout e un solo nuovo tentativo.

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

Il primo comando fornisce l’identificatore di connessione che il dispatcher deve corrispondere. Gli altri due mostrano se un tentativo è già in corso, e questo è il controllo che evita i duplicati.

Un servizio senza supervisione ha bisogno delle proprie credenziali approvate e della propria verifica dell’host nel proprio contesto di esecuzione. Non può presumere che un agente grafico sia sbloccato, e non dovrebbe tentare di sbloccarne uno.

Pianifica la disconnessione prima di forzare la pulizia

Per una disconnessione pianificata, completa le operazioni sui file e smonta dal flusso di lavoro dell’utente che monta. Punta al punto di mount invece che al processo, e conferma il risultato prima di segnalare il successo.

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

Smonta solo il mount creato da questo flusso di lavoro. Se è occupato, è una decisione dell’applicazione: un distacco forzato che esiste per far restituire successo a un hook nasconde la perdita di dati invece di prevenirla.

Una perdita imprevista si comporta diversamente. SSHFS documenta che un’interruzione di rete può bloccare un’operazione del file system, e l’opzione reconnect ripristina il trasporto senza ripristinare gli handle: un file aperto prima della riconnessione può fallire alla scrittura successiva, e una scrittura interrotta non viene conservata. Questa distinzione conta soprattutto per gli editor che tengono un file aperto per ore. Pianifica un passaggio di riapertura invece di presumere il ripristino.

Prova il comportamento con file usa e getta prima di affidarti ad esso. Una directory che riappare dopo il ritorno del tunnel non dimostra che gli handle precedenti o il lavoro non salvato siano sopravvissuti.