Ali naj uporabniška seja poseduje priklop SSHFS prek VPN?

Priklop skupne mape po dvigu VPN vključuje dve identiteti, ki ju je lahko zamenjati: komponento, ki sme konfigurirati omrežje, in račun, ki se sme prijaviti na strežnik datotek. Redko sta isti. Root VPN kavelj je slabo mesto za začetek priklopa SSHFS namiznega uporabnika, ker nima niti uporabnikovega agenta niti predvidenega lastništva priklopa. Če lastništvo najprej pravilno določimo, sprožilec postane preprost.

Dve identiteti, dve ločeni dovoljenji

Odjemalec VPN potrebuje privilegije za spreminjanje poti in vmesnikov. Priklop SSHFS potrebuje identiteto SSH, ki jo strežnik datotek sprejme, in priklop FUSE v lasti računa, ki bo bral datoteke. Ena skripta, ki teče kot root, izpolni prvo zahtevo in tiho prekrši drugo.

Priklop kot root pusti datoteke zunaj namizne seje in morda brez dostopa do agenta, ki hrani uporabnikov ključ. Priklop obstaja, uporabnik ne more pisati skozenj, in napaka je videti kot težava z dovoljenji na strani strežnika. Ta napačna diagnoza stane popoldne in zahtevek ekipi za shranjevanje.

Odločite se, kateri račun ima priklop v lasti, preden napišete kakršno koli avtomatizacijo, ker ta izbira določa, kje živi sprožilec in do katerih poverilnic lahko pride.

Najprej ročno vzpostavite uporabniku lasten priklop

Začnite s prijavljenim uporabnikom s prazno priklopno točko, pooblaščenim računom SSH in delujočo potjo do strežnika skozi tunel. Ročni priklop vzpostavi osnovo, ki jo mora vsaka avtomatizacija poustvariti.

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

Imena so primeri, zato zamenjajte gostitelja in izvozno pot, ki ju vaš strežnik dejansko ponuja. Preverite ključ gostitelja po odobrenem postopku pri prvi povezavi. Upoštevajte, da geslo računa VPN ni samodejno poverilnica računa za shranjevanje, in to je pogost vzrok neuspešnih poskusov.

Zaženite ga kot običajen uporabnik s priklopno točko, ki je v lasti tega uporabnika. Privzeto le račun, ki priklaplja, doseže datoteke, in allow_other razširi to mejo na vsakega lokalnega uporabnika. To je namerna razširitev dostopa, ne obvoz za avtomatizacijo.

Naj sprožilec deluje v istem kontekstu seje

Naj podprta integracija dogodkov VPN zahteva izvedbo dejanja uporabniške seje, namesto da bi predpostavili, da si privilegirani callback lahko izposodi namizno poverilnico. Omejite sprožilec na predvideni identifikator povezave in ne na kateri koli vmesnik, ki se slučajno imenuje tun0. Pravilo razpošiljatelja, ki se ujema z napačno stvarjo, se sproži ob vsaki spremembi omrežja, tudi tistih, ki nimajo nič skupnega s tem priklopom.

Dejanje bi moralo potrditi pričakovano ime gostitelja, opaziti obstoječi priklop in narediti en omejen poskus. Zanka anketiranja, ki vsakih nekaj sekund zažene nov proces SSHFS ali ponovi zahtevo za poverilnice, medtem ko strežnik ne deluje, spremeni kratek izpad v kup zataknjenih procesov. Omejite poskus s časovno omejitvijo in enim ponovnim poskusom.

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

Prvi ukaz poda identifikator povezave, s katerim se mora razpošiljatelj ujemati. Druga dva pokažeta, ali poskus že teče, in to je preverjanje, ki preprečuje dvojnike.

Nenadzorovana storitev potrebuje lastne odobrene poverilnice in lastno preverjanje gostitelja v svojem kontekstu izvajanja. Ne more predpostaviti, da je grafični agent odklenjen, in ne bi smela poskušati odkleniti enega.

Načrtujte odklop, preden vsilite čiščenje

Pri načrtovanem odklopu dokončajte datotečne operacije in odklopite iz lastnega delovnega toka uporabnika, ki priklaplja. Ciljajte na priklopno točko in ne na proces, ter potrdite rezultat, preden poročate o uspehu.

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

Odklopite samo priklop, ki ga je ustvaril ta delovni tok. Če je zaseden, je to odločitev aplikacije: vsiljena ločitev, ki obstaja zato, da kavelj vrne uspeh, skrije izgubo podatkov, namesto da bi jo preprečila.

Nepričakovana izguba se obnaša drugače. SSHFS dokumentira, da lahko prekinitev omrežja blokira datotečno operacijo, in možnost reconnect obnovi prenos brez obnovitve ročic: datoteka, odprta pred ponovno povezavo, lahko pri naslednjem pisanju ne uspe, in prekinjeno pisanje se ne ohrani. Ta razlika je najpomembnejša za urejevalnike, ki imajo eno datoteko odprto ure in ure. Načrtujte korak ponovnega odpiranja, namesto da predpostavite obnovitev.

Preizkusite obnašanje z datotekami za enkratno uporabo, preden se nanj zanesete. Mapa, ki se po vrnitvi tunela znova pojavi, ne dokazuje, da so prejšnje ročice ali neshranjena dela preživela.