Bør brukersesjonen eie SSHFS-monteringen over VPN?

Montering av en delt mappe etter at VPN-en er oppe innebærer to identiteter som er lette å forveksle: komponenten som har lov til å konfigurere nettverket, og kontoen som har lov til å logge på filserveren. De er sjelden den samme. En root-eid VPN-krok er et dårlig sted å starte en skrivebordsbrukers SSHFS-montering, fordi den verken har brukerens agent eller det tiltenkte monteringseierskapet. Når eierskapet først er riktig, blir utløseren enkel.

To identiteter, to separate tillatelser

VPN-klienten trenger privilegier for å endre ruter og grensesnitt. SSHFS-monteringen trenger en SSH-identitet som filserveren godtar, og en FUSE-montering som eies av kontoen som skal lese filene. Ett skript som kjører som root oppfyller det første kravet og bryter stilltiende det andre.

Montering som root lar filene ligge utenfor skrivebordsøkten og muligens uten tilgang til agenten som holder brukerens nøkkel. Monteringen finnes, brukeren kan ikke skrive gjennom den, og feilen ser ut som et tillatelsesproblem på serversiden. Den feildiagnosen koster en ettermiddag og en billett til lagringsteamet.

Bestem hvilken konto som eier monteringen før du skriver noen automatisering, fordi det valget avgjør hvor utløseren bor og hvilke legitimasjoner den kan nå.

Opprett først en brukereid montering manuelt

Start med en innlogget bruker med et tomt monteringspunkt, en autorisert SSH-konto og en fungerende sti til serveren gjennom tunnelen. En manuell montering etablerer grunnlaget som enhver automatisering må gjenskape.

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

Navnene er eksempler, så bytt ut vertsnavnet og eksportstien som serveren din faktisk tilbyr. Bekreft vertsnøkkelen gjennom den godkjente prosessen ved den første tilkoblingen. Merk at et VPN-kontopassord ikke automatisk er legitimasjonen til lagringskontoen, og det er en vanlig årsak til mislykkede forsøk.

Kjør det som en vanlig bruker med et monteringspunkt som den brukeren eier. Som standard er det bare kontoen som monterer, som når filene, og allow_other utvider den grensen til hver lokal bruker. Det er en bevisst utvidelse av tilgangen, ikke en omvei for automatisering.

La utløseren handle i samme øktkontekst

La den støttede VPN-hendelsesintegrasjonen be om at en brukersesjonshandling kjøres, i stedet for å anta at en privilegert callback kan låne en skrivebordslegitimasjon. Begrens utløseren til den tiltenkte tilkoblingsidentifikatoren i stedet for til et hvilket som helst grensesnitt som tilfeldigvis heter tun0. En dispatcher-regel som matcher feil ting, utløses ved hver nettverksendring, også de som ikke har noe med denne monteringen å gjøre.

Handlingen bør bekrefte det forventede vertsnavnet, legge merke til en eksisterende montering og gjøre ett begrenset forsøk. En avspørringssløyfe som starter en ny SSHFS-prosess hvert par sekunder, eller gjentar en legitimasjonsforespørsel mens serveren er nede, gjør en kort avbrudd til en haug med fastlåste prosesser. Begrens forsøket med en tidsavbrudd og ett enkelt nytt forsøk.

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

Den første kommandoen gir tilkoblingsidentifikatoren som dispatcheren skal matche. De to andre viser om et forsøk allerede kjører, og det er kontrollen som forhindrer duplikater.

En uovervåket tjeneste trenger sine egne godkjente legitimasjoner og sin egen vertsbekreftelse i sin egen kjørekontekst. Den kan ikke anta at en grafisk agent er ulåst, og den bør ikke prøve å låse opp en.

Planlegg frakoblingen før du tvinger oppryddingen

Ved en planlagt frakobling, fullfør filoperasjonene og avmonter fra den monterende brukerens eget arbeidsløp. Rett deg mot monteringspunktet i stedet for prosessen, og bekreft resultatet før du rapporterer suksess.

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

Avmonter bare monteringen som dette arbeidsløpet opprettet. Hvis den er opptatt, er det en beslutning i applikasjonen: en tvungen frakobling som finnes for å få en krok til å returnere suksess, skjuler datatap i stedet for å forhindre det.

Uventet tap oppfører seg annerledes. SSHFS dokumenterer at en nettverksavbrudd kan blokkere en filsystemoperasjon, og reconnect-alternativet gjenoppretter transporten uten å gjenopprette handles: en fil som ble åpnet før gjenoppkoblingen, kan feile ved neste skriving, og en avbrutt skriving bevares ikke. Den forskjellen betyr mest for editorer som holder én fil åpen i timer. Planlegg et trinn med gjenåpning i stedet for å anta gjenoppretting.

Test oppførselen med engangsfiler før du stoler på den. En mappe som dukker opp igjen etter at tunnelen kommer tilbake, beviser ikke at tidligere handles eller ulagret arbeid overlevde.