Bør brukarsesjonen eige SSHFS-monteringa over VPN?

Montering av ei delt mappe etter at VPN-en er oppe inneber to identitetar som er lette å forveksle: komponenten som har løyve til å konfigurere nettet, og kontoen som har løyve til å logge på filserveren. Dei er sjeldan den same. Ein root-eigd VPN-krok er ein dårleg stad å starte SSHFS-monteringa til ein skrivebordsbrukar, fordi han verken har agenten til brukaren eller det tiltenkte monteringseigarskapet. Når eigarskapet først er rett, blir utløysaren enkel.

To identitetar, to separate løyve

VPN-klienten treng privilegium for å endre ruter og grensesnitt. SSHFS-monteringa treng ein SSH-identitet som filserveren godtek, og ei FUSE-montering som er eigd av kontoen som skal lese filene. Eitt skript som køyrer som root oppfyller det første kravet og bryt stille det andre.

Montering som root lèt filene ligge utanfor skrivebordsøkta og moglegvis utan tilgang til agenten som held nøkkelen til brukaren. Monteringa finst, brukaren kan ikkje skrive gjennom ho, og feilen ser ut som eit løyveproblem på serversida. Den feildiagnosen kostar ein ettermiddag og ein billett til lagringsteamet.

Bestem kva konto som eig monteringa før du skriv nokon automatisering, fordi det valet avgjer kvar utløysaren bur og kva legitimasjonar han kan nå.

Opprett først ei brukareigd montering manuelt

Start med ein innlogga brukar med eit tomt monteringspunkt, ein autorisert SSH-konto og ein fungerande sti til serveren gjennom tunnelen. Ei manuell montering etablerer grunnlaget som kvar automatisering må gjenskape.

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

Namna er døme, så byt ut vertsnamnet og eksportstien som serveren din faktisk tilbyr. Stadfest vertsnøkkelen gjennom den godkjende prosessen ved den første tilkoplinga. Merk at eit VPN-kontopassord ikkje automatisk er legitimasjonen til lagringskontoen, og det er ein vanleg årsak til mislukka forsøk.

Køyr det som ein vanleg brukar med eit monteringspunkt som den brukaren eig. Som standard er det berre kontoen som monterer, som når filene, og allow_other utvidar den grensa til kvar lokal brukar. Det er ei medviten utviding av tilgangen, ikkje ein omveg for automatisering.

Lat utløysaren handle i same øktkontekst

Lat den støtta VPN-hendingsintegrasjonen be om at ei brukarsesjonshandling blir køyrd, i staden for å anta at ein privilegert callback kan låne ein skrivebordslegitimasjon. Avgrens utløysaren til den tiltenkte tilkoplinga sin identifikator i staden for til eit kva som helst grensesnitt som tilfeldigvis heiter tun0. Ein dispatcher-regel som passar på feil ting, blir utløyst ved kvar nettverksendring, også dei som ikkje har noko med denne monteringa å gjere.

Handlinga bør stadfeste det forventa vertsnamnet, leggje merke til ei eksisterande montering og gjere eitt avgrensa forsøk. Ei avspørringssløyfe som startar ein ny SSHFS-prosess kvart par sekund, eller gjentek ein legitimasjonsførespurnad medan serveren er nede, gjer eit kort avbrot til ein haug med fastlåste prosessar. Avgrens forsøket med ein tidsavbrot og eitt enkelt nytt forsøk.

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

Den første kommandoen gir tilkoplinga sin identifikator som dispatcheren skal matche. Dei to andre viser om eit forsøk alt køyrer, og det er kontrollen som hindrar duplikat.

Ein uovervaka teneste treng sine eigne godkjende legitimasjonar og si eiga vertsstadfesting i sin eigen køyringskontekst. Ho kan ikkje anta at ein grafisk agent er ulåst, og ho bør ikkje prøve å låse opp ein.

Planlegg fråkoplinga før du tvingar oppryddinga

Ved ei planlagd fråkopling, fullfør filoperasjonane og avmonter frå arbeidsflyten til den monterande brukaren sjølv. Rett deg mot monteringspunktet i staden for prosessen, og stadfest resultatet før du rapporterer suksess.

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

Avmonter berre monteringa som denne arbeidsflyten oppretta. Viss ho er oppteken, er det ei avgjerd i applikasjonen: ei tvinga fråkopling som finst for å få ein krok til å returnere suksess, skjuler datatap i staden for å hindre det.

Uventa tap oppfører seg annleis. SSHFS dokumenterer at eit nettverksavbrot kan blokkere ein filsystemoperasjon, og reconnect-alternativet gjenopprettar transporten utan å gjenopprette handtak: ei fil som blei opna før gjenoppkoplinga, kan feile ved neste skriving, og ei avbroten skriving blir ikkje bevart. Den skilnaden betyr mest for editorar som held éi fil open i timar. Planlegg eit trinn med gjenopning i staden for å anta gjenoppretting.

Test oppførselen med eingongs filer før du stolar på han. Ei mappe som dukkar opp igjen etter at tunnelen kjem tilbake, beviser ikkje at tidlegare handtak eller ulagra arbeid overlevde.