Je, kikao cha mtumiaji kinapaswa kumiliki mount ya SSHFS juu ya VPN?

Ku-mount folda inayoshirikiwa baada ya VPN kupanda kunahusisha utambulisho mbili ambazo ni rahisi kuchanganya: sehemu inayoruhusiwa kusanidi mtandao, na akaunti inayoruhusiwa kuingia kwenye seva ya faili. Mara chache huwa sawa. Hook ya VPN inayomilikiwa na root ni mahali pabaya pa kuanza mount ya SSHFS ya mtumiaji wa eneo-kazi, kwa sababu haina wakala wa mtumiaji wala umiliki wa mount uliokusudiwa. Kupanga umiliki kwa usahihi kwanza hufanya kichocheo kuwa rahisi.

Utambulisho mbili, ruhusa mbili tofauti

Mteja wa VPN anahitaji mamlaka ya kubadilisha njia na violesura. Mount ya SSHFS inahitaji utambulisho wa SSH unaokubaliwa na seva ya faili na mount ya FUSE inayomilikiwa na akaunti itakayosoma faili. Skripti moja inayoendesha kama root inatimiza sharti la kwanza na kuvunja la pili kimya.

Ku-mount kama root kunaacha faili nje ya kikao cha eneo-kazi na pengine bila ufikiaji wa wakala anayeshikilia ufunguo wa mtumiaji. Mount ipo, mtumiaji hawezi kuandika kupitia hiyo, na hitilafu inaonekana kama tatizo la ruhusa upande wa seva. Utambuzi huo mbaya unagharimu mchana na tiketi kwa timu ya hifadhi.

Amua ni akaunti gani inamiliki mount kabla ya kuandika uendeshaji wowote, kwa sababu chaguo hilo huamua mahali kichocheo kinaishi na ni vitambulisho vipi inaweza kufikia.

Kwanza simamisha kwa mkono mount inayomilikiwa na mtumiaji

Anza na mtumiaji aliyeingia mwenye mahali pa mount tupu, akaunti ya SSH iliyoidhinishwa na njia inayofanya kazi kwa seva kupitia handaki. Mount ya mkono huanzisha msingi ambao uendeshaji wowote lazima uufanye upya.

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

Majina ni mifano, kwa hivyo badilisha mwenyeji na njia ya kusafirisha ambazo seva yako inatoa kwa kweli. Thibitisha ufunguo wa mwenyeji kupitia mchakato ulioidhinishwa kwenye muunganisho huo wa kwanza. Kumbuka kuwa nenosiri la akaunti ya VPN si kitambulisho cha akaunti ya hifadhi kiotomatiki, na hiyo ni sababu ya kawaida ya majaribio yaliyoshindikana.

Iendeshe kama mtumiaji wa kawaida mwenye mahali pa mount panapomilikiwa na mtumiaji huyo. Kwa chaguo-msingi akaunti inayo-mount pekee hufikia faili, na allow_other hupanua mpaka huo kwa kila mtumiaji wa ndani. Hiyo ni upanuzi wa ufikiaji kwa makusudi, si njia mbadala ya uendeshaji.

Acha kichocheo kitende kazi katika muktadha huo huo wa kikao

Acha muunganisho wa matukio ya VPN unaotumika uombe kitendo cha kikao cha mtumiaji kiendeshwe, badala ya kudhani callback yenye mamlaka inaweza kukopa kitambulisho cha eneo-kazi. Weka kichocheo kwenye kitambulisho cha muunganisho kilichokusudiwa na si kwenye kiolesura chochote kinachoitwa tun0 kwa bahati. Sheria ya msambazaji inayolingana na kitu kibaya huwaka kwenye kila mabadiliko ya mtandao, ikiwa ni pamoja na yale yasiyohusiana na mount hii.

Kitendo kinapaswa kuthibitisha jina la mwenyeji linalotarajiwa, kugundua mount iliyopo na kufanya jaribio moja lenye mipaka. Kitanzi cha uchunguzi kinachoanzisha mchakato mpya wa SSHFS kila sekunde chache, au kurudia ombi la kitambulisho wakati seva imezimwa, hugeuza usumbufu mfupi kuwa rundo la michakato iliyokwama. Weka kikomo cha jaribio kwa muda na jaribio moja la kurudia.

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

Amri ya kwanza inatoa kitambulisho cha muunganisho ambacho msambazaji anapaswa kulinganisha. Mbili zingine zinaonyesha ikiwa jaribio tayari linaendelea, na hiyo ndiyo ukaguzi unaozuia nakala.

Huduma isiyosimamiwa inahitaji vitambulisho vyake vilivyoidhinishwa na uthibitishaji wake wa mwenyeji katika muktadha wake wa utekelezaji. Haiwezi kudhani wakala wa picha amefunguliwa, na haipaswi kujaribu kufungua mmoja.

Panga kukatwa kabla ya kulazimisha usafishaji

Kwa kukatwa kuliopangwa, kamilisha shughuli za faili na uondoe kutoka kwa mtiririko wa kazi wa mtumiaji anaye-mount mwenyewe. Lenga mahali pa mount badala ya mchakato, na thibitisha matokeo kabla ya kuripoti mafanikio.

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

Ondoa mount tu iliyoundwa na mtiririko huu wa kazi. Ikiwa ina shughuli, hiyo ni uamuzi wa programu: kutenganisha kwa nguvu kunakuwepo ili hook irudishe mafanikio huficha upotevu wa data badala ya kuuzuia.

Upotevu usiotarajiwa hufanya tofauti. SSHFS inaandika kwamba usumbufu wa mtandao unaweza kuzuia operesheni ya mfumo wa faili, na chaguo la reconnect hurejesha usafirishaji bila kurejesha handles: faili iliyofunguliwa kabla ya kuunganisha tena inaweza kushindikana kwenye uandishi unaofuata, na uandishi uliokatizwa hauhifadhiwi. Tofauti hiyo ni muhimu zaidi kwa wahariri wanaoshikilia faili moja wazi kwa masaa. Panga hatua ya kufungua tena badala ya kudhani urejeshaji.

Jaribu tabia kwa faili za kutupwa kabla ya kuitegemea. Saraka inayotokea tena baada ya handaki kurudi haithibitishi kuwa handles za awali au kazi isiyohifadhiwa zilinusurika.