SSHFS-koppelpunte hoort aan die gebruiker, nie aan die VPN-haak nie

Die aanname is maklik om aan te neem en moeilik om raak te sien: 'n VPN-koppelhaak loop as root, so die koppelpunt wat dit begin, moet ook as root gereël word. Daardie redenasie lewer 'n spanmap wat die lessenaargebruiker nie kan oopmaak nie, 'n koppelpunt wat verdwyn wanneer die snellerediens herbegin, en 'n stawingsvraag in 'n konteks waar niemand dit kan antwoord nie. Die haak en die koppelpunt is twee verskillende take, en net een van hulle het voorreg nodig.

Die mite: netwerkvoorreg beteken koppelvoorreg

Om 'n koppelvlak te lig en by 'n lêerbundel te verifieer, is onverwante vermoëns, en hulle hoort gewoonlik aan verskillende rekeninge. Die VPN-komponent het genoeg voorreg nodig om roetes en koppelvlakke te verander. Die lêerbundelrekening het 'n sleutel of 'n wagwoord, 'n besluit oor die gasheersleutel en 'n tuisgids nodig om in te koppel. Om die tweede taak se geloofsbriewe aan die eerste identiteit te gee, is hoe 'n netwerkdiens 'n gebruiker se sleutel begin hou.

Op 'n enkelgebruiker-skootrekenaar kan dit dieselfde rekening wees, en daardie toevalligheid is nie 'n ontwerp nie.

Sodra 'n bevoorregte haak die koppeling doen, gaan drie dinge stil verkeerd. Die koppelpunt word deur root besit, die gebruiker se agent is afwesig uit daardie omgewing, en foute verskyn in die netwerkdiens se logboek eerder as in die sessie wat omgee. Nie een daarvan word herstel deur opsies by die koppelopdrag te voeg nie. Hulle word herstel deur die taak aan die sessie te gee wat die identiteit besit.

Waarom die koppelpunt aan die aangemelde gebruiker hoort

'n SSHFS-koppelpunt is 'n FUSE-koppelpunt wat deur die proses besit word wat dit geskep het, en toegang volg daardie eienaarskap eerder as die moedergids se modus. Die verwysing beveel 'n gewone gebruiker aan met 'n koppelpunt wat daardie gebruiker besit, en dit is presies waarom 'n koppelpunt wat deur 'n root-proses geskep is, vir almal anders ongemaklik is. 'n Toestemmingverandering op die koppelpunt herstel dit nie, want die struikelblok is die koppelpunt se eie eienaar.

Begin met 'n handmatige basislyn binne die gebruiker se sessie: 'n bestaande leë koppelpunt onder die tuisgids, 'n gemagtigde rekening op die bediener, en 'n gasheersleutel wat al deur jou goedgekeurde proses verifieer is. Koppel dit een keer met die hand en gebruik dit, want dit bewys dat die identiteitspad werk voordat enige outomatisering bestaan. Let op wat die opdrag nodig gehad het: die rekeningnaam, die uitvoerpad en die privaat gasheernaam. Hou daardie presiese konteks vir die geoutomatiseerde weergawe, want 'n werkende handmatige koppelpunt is die spesifikasie wat die sneller moet reproduseer.

sshfs [email protected]:/exports/team "$HOME/mnt/team"

Behandel elke naam en pad in daardie reël as 'n plekhouer, insluitend die rekening en die uitvoer. 'n VPN-rekeningwagwoord is nie outomaties die bergingsrekening se geloofsbrief nie.

Wat die sneller die sessie moet vra om te doen

Die ondersteunde reëling is 'n versoek van die netwerkgebeurtenis aan die gebruiker se sessie, nie 'n geleende geloofsbrief nie. Beperk die sneller tot die verbinding wat jy bedoel, by naam of UUID, eerder as tot enige koppelvlak wat toevallig tun0 heet. Daardie enkele verandering keer dat 'n tweede profiel, 'n toets-tonnel of 'n kollega se ontfoutingsessie 'n koppelpunt begin.

Die sessie-kant aksie moet na die bedoelde bestaande koppelpunt soek en dan een begrensde poging doen.

Moenie by elke peiling weer probeer nie, en moenie aanhou vra vir 'n geloofsbrief terwyl die bediener onbereikbaar is nie, want albei verander 'n tydelike onderbreking in 'n rekeninguitsluiting. 'n Onbewaakte diens is 'n aparte ontwerp met sy eie goedgekeurde geloofsbrief en gasheerverifiëring-reëling in sy eie uitvoeringskonteks, en dit kan nie daarop staatmaak dat iemand 'n grafiese agent oopgesluit het nie. Besluit watter van die twee jy bou voordat jy kies waar die kode woon. Die meeste van die verwarring hier kom daarvan dat 'n mens een bou en die ander verwag.

Ontkoppeling is 'n lêerstelsel-gebeurtenis, nie 'n haak-gebeurtenis nie

'n Beplande ontkoppeling moet lêerbewerkings voltooi en uit die koppelende gebruiker se sessie ontkoppel met die ondersteunde opdrag vir daardie lêerstelseltipe. Om 'n losmaking af te dwing sodat 'n haak vinnig terugkeer, is hoe toepassings hul werkende gids verloor en gebruikers vertroue in die outomatisering verloor. 'n Besige koppelpunt het 'n besluit op toepassingsvlak nodig, soos om die lêer te sluit of die skryf te stop, nie 'n sterker sein nie. Die haak se afsluitstatus is nie die ding wat geoptimaliseer word nie.

fusermount3 -u "$HOME/mnt/team"

Onverwagte verlies is 'n ander geval, en SSHFS dokumenteer dat 'n onderbroke bewerking kan blokkeer terwyl die vervoer weer verbind.

Die herverbindingsopsie herstel die vervoer, en lêers wat voor daardie herverbinding oopgemaak is, kan steeds foute teruggee en moet weer oopgemaak word. 'n Terugkerende VPN bewys niks oor vroeëre handvatsels of ongestoorde werk nie. Kies die gedrag wat jy tydens 'n onderbreking wil hê, of dit nou pouseer, 'n fout wys of doelbewus herkoppel is, en toets dit met weggooilêers voordat enigiets daarvan afhang.