Vai lietotāja sesijai jāpieder SSHFS montējumam VPN ietvaros?

Koplietojamas mapes montēšana pēc VPN pacelšanas ietver divas identitātes, kuras ir viegli sajaukt: komponentu, kam atļauts konfigurēt tīklu, un kontu, kam atļauts pieteikties failu serverī. Tās reti ir vienas. Root piederīgs VPN āķis ir slikta vieta, lai sāktu darbvirsmas lietotāja SSHFS montējumu, jo tam nav ne lietotāja aģenta, ne paredzētās montējuma piederības. Ja piederība vispirms tiek noteikta pareizi, trigeris kļūst vienkāršs.

Divas identitātes, divas atsevišķas atļaujas

VPN klientam ir vajadzīgas privilēģijas, lai mainītu maršrutus un saskarnes. SSHFS montējumam ir vajadzīga SSH identitāte, ko pieņem failu serveris, un FUSE montējums, kas pieder kontam, kurš lasīs failus. Viens skripts, kas darbojas kā root, izpilda pirmo prasību un klusi salauž otro.

Montēšana kā root atstāj failus ārpus darbvirsmas sesijas un, iespējams, bez piekļuves aģentam, kas glabā lietotāja atslēgu. Montējums pastāv, lietotājs nevar caur to rakstīt, un kļūme izskatās kā servera puses atļauju problēma. Šāda nepareiza diagnoze maksā pēcpusdienu un biļeti uz glabāšanas komandu.

Izlemiet, kuram kontam pieder montējums, pirms rakstāt jebkādu automatizāciju, jo šī izvēle nosaka, kur dzīvo trigeris un kādiem akreditācijas datiem tas var piekļūt.

Vispirms manuāli izveidojiet lietotājam piederošu montējumu

Sāciet ar pieteikušos lietotāju ar tukšu montējuma punktu, autorizētu SSH kontu un darba ceļu uz serveri caur tuneli. Manuāla montēšana nosaka pamatu, kas jāatkārto jebkurai automatizācijai.

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

Nosaukumi ir piemēri, tāpēc aizstājiet resursdatoru un eksporta ceļu, ko jūsu serveris patiešām piedāvā. Pārbaudiet resursdatora atslēgu ar apstiprināto procesu pirmajā savienojumā. Ņemiet vērā, ka VPN konta parole nav automātiski glabāšanas konta akreditācijas dati, un tas ir biežs neveiksmīgu mēģinājumu cēlonis.

Palaidiet to kā parastu lietotāju ar montējuma punktu, kas pieder šim lietotājam. Pēc noklusējuma failiem piekļūst tikai montējošais konts, un allow_other paplašina šo robežu uz katru vietējo lietotāju. Tā ir apzināta piekļuves paplašināšana, nevis automatizācijas apiešana.

Ļaujiet trigerim darboties tajā pašā sesijas kontekstā

Ļaujiet atbalstītajai VPN notikumu integrācijai pieprasīt lietotāja sesijas darbības palaišanu, tā vietā pieņemot, ka privileģēts callback var aizņemties darbvirsmas akreditācijas datus. Ierobežojiet trigeri ar paredzēto savienojuma identifikatoru, nevis ar jebkuru saskarni, kas nejauši saucas tun0. Dispečera noteikums, kas atbilst nepareizajai lietai, aktivizējas pie katras tīkla izmaiņas, tostarp tām, kurām nav nekāda sakara ar šo montējumu.

Darbībai jāapstiprina gaidītais resursdatora nosaukums, jāpamana esošais montējums un jāveic viens ierobežots mēģinājums. Aptaujas cilpa, kas ik pēc dažām sekundēm sāk jaunu SSHFS procesu vai atkārto akreditācijas datu pieprasījumu, kamēr serveris nedarbojas, pārvērš īsu pārtraukumu iesprūdušu procesu kaudzē. Ierobežojiet mēģinājumu ar taimautu un vienu atkārtojumu.

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

Pirmā komanda dod savienojuma identifikatoru, ar kuru dispečeram jāsakrīt. Pārējās divas parāda, vai mēģinājums jau notiek, un tā ir pārbaude, kas novērš dublikātus.

Neuzraudzītam pakalpojumam ir vajadzīgi savi apstiprināti akreditācijas dati un sava resursdatora pārbaude savā izpildes kontekstā. Tas nevar pieņemt, ka grafiskais aģents ir atslēgts, un tam nevajadzētu mēģināt to atslēgt.

Plānojiet atvienošanu pirms tīrīšanas piespiešanas

Plānotai atvienošanai pabeidziet failu operācijas un atmontējiet no montējošā lietotāja paša darbplūsmas. Mērķējiet uz montējuma punktu, nevis procesu, un apstipriniet rezultātu pirms ziņošanas par panākumiem.

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

Atmontējiet tikai to montējumu, ko izveidoja šī darbplūsma. Ja tas ir aizņemts, tas ir lietojumprogrammas lēmums: piespiedu atdalīšana, kas pastāv, lai āķis atgrieztu panākumus, slēpj datu zudumu, nevis novērš to.

Negaidīts zudums uzvedas citādi. SSHFS dokumentē, ka tīkla pārtraukums var bloķēt failu sistēmas operāciju, un opcija reconnect atjauno transportu, neatjaunojot rokturus: fails, kas atvērts pirms atkārtotas savienošanas, var neizdoties nākamajā rakstīšanā, un pārtraukta rakstīšana netiek saglabāta. Šī atšķirība ir vissvarīgākā redaktoriem, kuri vienu failu tur atvērtu stundām ilgi. Plānojiet atkārtotas atvēršanas soli, nevis pieņemiet atjaunošanu.

Pārbaudiet uzvedību ar vienreizlietojamiem failiem, pirms paļaujaties uz to. Mape, kas atkal parādās pēc tuneļa atgriešanās, nepierāda, ka iepriekšējie rokturi vai nesaglabātais darbs ir izdzīvojuši.