Kas kasutajaseanss peaks VPN-i kohal SSHFS-i mounti omama?

Jagatud kausta mountimine pärast VPN-i tõusmist hõlmab kahte identiteeti, mida on lihtne segi ajada: komponent, millel on lubatud võrku seadistada, ja konto, millel on lubatud failiserverisse sisse logida. Harva on need samad. Rootile kuuluv VPN-konks on halb koht töölauakasutaja SSHFS-i mounti alustamiseks, sest sellel pole ei kasutaja agenti ega kavandatud mounti omandit. Kui omand on esmalt õige, muutub päästik lihtsaks.

Kaks identiteeti, kaks eraldi luba

VPN-klient vajab privileege marsruutide ja liideste muutmiseks. SSHFS-i mount vajab SSH-identiteeti, mille failiserver vastu võtab, ja FUSE-mounti, mis kuulub kontole, kes faile loeb. Üks rootina jooksev skript täidab esimese nõude ja rikub vaikselt teise.

Rootina mountimine jätab failid töölauaseansist väljapoole ja võib-olla ilma juurdepääsuta agendile, mis hoiab kasutaja võtit. Mount on olemas, kasutaja ei saa selle kaudu kirjutada ja tõrge näeb välja nagu serveripoolne õiguste probleem. See vale diagnoos maksab pool päeva ja pileti salvestusmeeskonnale.

Otsustage, milline konto mounti omab, enne kui kirjutate mis tahes automatiseerimise, sest see valik määrab, kus päästik elab ja millistele volitustele see pääseb.

Looge esmalt käsitsi kasutajaomandis mount

Alustage sisselogitud kasutajast, kellel on tühi mountimispunkt, volitatud SSH-konto ja töötav tee serverini tunneli kaudu. Käsitsi mountimine loob aluse, mida iga automatiseerimine peab kordama.

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

Nimed on näited, seega asendage host ja eksporditee, mida teie server tegelikult pakub. Kontrollige hostivõtit heakskiidetud protsessi kaudu sellel esimesel ühendusel. Pange tähele, et VPN-konto parool ei ole automaatselt salvestuskonto volitus ja see on sagedane ebaõnnestunud katsete põhjus.

Käivitage see tavalise kasutajana, kellele kuulub mountimispunkt. Vaikimisi pääseb failidele ligi ainult mountiv konto ja allow_other laiendab seda piiri igale kohalikule kasutajale. See on juurdepääsu teadlik laiendamine, mitte automatiseerimise möödaviik.

Laske päästikul tegutseda samas seansikontekstis

Laske toetatud VPN-sündmuse integreerimisel paluda kasutajaseansi toimingut käivitada, selle asemel et eeldada, et privilegeeritud callback saab töölaua volitusi laenata. Piiridke päästik kavandatud ühenduse identifikaatoriga, mitte ühegi liidesega, mis juhtub kandma nime tun0. Valesse asja sobiv dispetšeri reegel vallandub iga võrgu muutuse korral, sealhulgas nende puhul, millel pole selle mountiga midagi pistmist.

Toiming peaks kinnitama oodatud hostinime, märkama olemasolevat mounti ja tegema ühe piiratud katse. Küsitlusahel, mis käivitab iga paari sekundi tagant uue SSHFS-protsessi või kordab volituste küsimist, kui server on maas, muudab lühikese katkestuse hunnikuks kinni jäänud protsessideks. Piirake katset ajapiirangu ja ühe korduskatsega.

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

Esimene käsk annab ühenduse identifikaatori, millega dispetšer peaks sobima. Ülejäänud kaks näitavad, kas katse juba jookseb, ja see on kontroll, mis hoiab ära duplikaadid.

Järelevalveta teenus vajab oma heakskiidetud volitusi ja oma hostikontrolli oma täitmiskontekstis. See ei saa eeldada, et graafiline agent on lukust lahti, ja see ei tohiks proovida seda avada.

Planeerige lahtiühendamine enne puhastuse sundimist

Planeeritud lahtiühendamise korral lõpetage failitoimingud ja mountige lahti mountiva kasutaja enda töövoost. Sihtige mountimispunkti, mitte protsessi, ja kinnitage tulemus enne edu teatamist.

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

Mountige lahti ainult see mount, mille see töövoog lõi. Kui see on hõivatud, on see rakenduse otsus: sunnitud lahutamine, mis on mõeldud selleks, et konks annaks edule vastuse, varjab andmekadu selle vältimise asemel.

Ootamatu kadu käitub teisiti. SSHFS dokumenteerib, et võrgukatkestus võib failisüsteemi toimingu blokeerida, ja valik reconnect taastab transpordi ilma käepidemeid taastamata: enne taasühendamist avatud fail võib järgmisel kirjutamisel ebaõnnestuda ja katkenud kirjutist ei säilitata. See erinevus on kõige olulisem redaktoritele, kes hoiavad ühte faili tunde lahti. Planeerige uuesti avamise samm, selle asemel et taastumist eeldada.

Testige käitumist ühekordsete failidega enne, kui sellele loote. Kataloog, mis ilmub uuesti pärast tunneli naasmist, ei tõesta, et varasemad käepidemed või salvestamata töö jäid alles.