Ar vartotojo sesija turi valdyti SSHFS prijungimą per VPN?

Bendro aplanko prijungimas po VPN įjungimo apima dvi tapatybes, kurias lengva supainioti: komponentą, kuriam leidžiama konfigūruoti tinklą, ir paskyrą, kuriai leidžiama prisijungti prie failų serverio. Jos retai būna tos pačios. Root valdomas VPN kabliukas yra bloga vieta pradėti darbalaukio vartotojo SSHFS prijungimą, nes jis neturi nei vartotojo agento, nei numatytosios prijungimo nuosavybės. Jei nuosavybė pirmiausia nustatoma teisingai, trigeris tampa paprastas.

Dvi tapatybės, du atskiri leidimai

VPN klientui reikia privilegijų keisti maršrutus ir sąsajas. SSHFS prijungimui reikia SSH tapatybės, kurią priima failų serveris, ir FUSE prijungimo, priklausančio paskyrai, kuri skaitys failus. Vienas scenarijus, veikiantis kaip root, tenkina pirmąjį reikalavimą ir tyliai sulaužo antrąjį.

Prijungimas kaip root palieka failus už darbalaukio sesijos ribų ir galbūt be prieigos prie agento, laikančio vartotojo raktą. Prijungimas egzistuoja, vartotojas negali per jį rašyti, o gedimas atrodo kaip serverio pusės leidimų problema. Tokia klaidinga diagnozė kainuoja popietę ir bilietą saugyklos komandai.

Nuspręskite, kuri paskyra valdo prijungimą, prieš rašydami bet kokią automatizaciją, nes šis pasirinkimas lemia, kur gyvena trigeris ir kokius kredencialus jis gali pasiekti.

Pirmiausia rankiniu būdu sukurkite vartotojo valdomą prijungimą

Pradėkite nuo prisijungusio vartotojo su tuščiu prijungimo tašku, autorizuota SSH paskyra ir veikiančiu keliu į serverį per tunelį. Rankinis prijungimas nustato pagrindą, kurį turi atkartoti bet kokia automatizacija.

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

Pavadinimai yra pavyzdžiai, todėl pakeiskite hostą ir eksporto kelią, kuriuos jūsų serveris iš tikrųjų siūlo. Patikrinkite hosto raktą patvirtintu procesu per pirmąjį prisijungimą. Atkreipkite dėmesį, kad VPN paskyros slaptažodis nėra automatiškai saugyklos paskyros kredencialas, ir tai yra dažna nepavykusių bandymų priežastis.

Vykdykite jį kaip įprastas vartotojas su prijungimo tašku, priklausančiu tam vartotojui. Pagal numatytuosius nustatymus tik prijungianti paskyra pasiekia failus, o allow_other išplečia šią ribą kiekvienam vietiniam vartotojui. Tai sąmoningas prieigos išplėtimas, o ne automatizacijos apėjimas.

Leiskite trigeriui veikti tame pačiame sesijos kontekste

Leiskite palaikomai VPN įvykių integracijai paprašyti paleisti vartotojo sesijos veiksmą, užuot darant prielaidą, kad privilegijuotas callback gali pasiskolinti darbalaukio kredencialą. Apribokite trigerį numatytam jungties identifikatoriui, o ne bet kuriai sąsajai, kuri atsitiktinai vadinama tun0. Dispečerio taisyklė, atitinkanti netinkamą dalyką, suveikia kiekvieną tinklo pasikeitimą, įskaitant tuos, kurie neturi nieko bendra su šiuo prijungimu.

Veiksmas turėtų patvirtinti laukiamą hosto vardą, pastebėti esamą prijungimą ir atlikti vieną ribotą bandymą. Apklausos ciklas, kuris kas kelias sekundes paleidžia naują SSHFS procesą arba kartoja kredencialų užklausą, kol serveris neveikia, trumpą sutrikimą paverčia įstrigusių procesų krūva. Apribokite bandymą laiko limitu ir vienu pakartojimu.

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

Pirmoji komanda pateikia jungties identifikatorių, kurį dispečeris turėtų atitikti. Kitos dvi rodo, ar bandymas jau vyksta, ir tai yra patikra, kuri apsaugo nuo dublikatų.

Neprižiūrimai tarnybai reikia savo patvirtintų kredencialų ir savo hosto patikros savo vykdymo kontekste. Ji negali manyti, kad grafinis agentas yra atrakintas, ir neturėtų bandyti jo atrakinti.

Suplanuokite atjungimą prieš priversdami valymą

Planuojamam atjungimui užbaikite failų operacijas ir atjunkite iš prijungiančio vartotojo darbo eigos. Taikykite į prijungimo tašką, o ne į procesą, ir patvirtinkite rezultatą prieš pranešdami apie sėkmę.

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

Atjunkite tik tą prijungimą, kurį sukūrė ši darbo eiga. Jei jis užimtas, tai programos sprendimas: priverstinis atskyrimas, egzistuojantis tam, kad kabliukas grąžintų sėkmę, slepia duomenų praradimą, o ne užkerta jam kelią.

Netikėtas praradimas elgiasi kitaip. SSHFS dokumentuoja, kad tinklo pertraukimas gali užblokuoti failų sistemos operaciją, o parinktis reconnect atkuria transportą neatkurdama rankenų: failas, atidarytas prieš pakartotinį prisijungimą, gali nepavykti kitame įraše, o pertrauktas įrašas neišsaugomas. Šis skirtumas svarbiausias redaktoriams, kurie vieną failą laiko atidarytą valandų valandas. Suplanuokite pakartotinio atidarymo žingsnį, o ne darykite prielaidą apie atkūrimą.

Išbandykite elgseną su vienkartiniais failais, prieš ja pasikliaudami. Katalogas, kuris vėl pasirodo po tunelio grįžimo, neįrodo, kad ankstesnės rankenos ar neišsaugotas darbas išliko.