Mala by používateľská relácia vlastniť SSHFS pripojenie cez VPN?

Pripojenie zdieľaného priečinka po spustení VPN zahŕňa dve identity, ktoré sa dajú ľahko zameniť: komponent, ktorý smie konfigurovať sieť, a účet, ktorý sa smie prihlásiť na súborový server. Zriedka sú rovnaké. VPN hák vlastnený rootom je zlé miesto na začatie SSHFS pripojenia používateľa pracovnej plochy, pretože nemá ani agenta používateľa, ani zamýšľané vlastníctvo pripojenia. Keď sa vlastníctvo najprv nastaví správne, spúšťač je jednoduchý.

Dve identity, dve oddelené oprávnenia

Klient VPN potrebuje oprávnenia na zmenu trás a rozhraní. SSHFS pripojenie potrebuje identitu SSH, ktorú súborový server prijme, a pripojenie FUSE vlastnené účtom, ktorý bude súbory čítať. Jeden skript spustený ako root splní prvú požiadavku a potichu poruší druhú.

Pripojenie ako root necháva súbory mimo relácie pracovnej plochy a možno bez prístupu k agentovi, ktorý drží kľúč používateľa. Pripojenie existuje, používateľ cez neho nemôže zapisovať a zlyhanie vyzerá ako problém s oprávneniami na strane servera. Táto chybná diagnóza stojí popoludnie a tiket pre tím úložiska.

Rozhodnite, ktorý účet vlastní pripojenie, skôr než napíšete akúkoľvek automatizáciu, pretože táto voľba určuje, kde spúšťač žije a ku ktorým prihlasovacím údajom sa môže dostať.

Najprv ručne vytvorte pripojenie vlastnené používateľom

Začnite s prihláseným používateľom s prázdnym prípomným bodom, autorizovaným účtom SSH a funkčnou cestou k serveru cez tunel. Ručné pripojenie stanovuje základ, ktorý musí každá automatizácia reprodukovať.

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

Názvy sú príklady, takže nahraďte hostiteľa a exportnú cestu, ktoré váš server skutočne ponúka. Overte kľúč hostiteľa schváleným postupom pri tomto prvom pripojení. Všimnite si, že heslo účtu VPN nie je automaticky prihlasovacím údajom účtu úložiska, a to je častá príčina neúspešných pokusov.

Spustite ho ako bežný používateľ s prípomným bodom, ktorý tomuto používateľovi patrí. Predvolene sa k súborom dostane iba účet, ktorý pripája, a allow_other rozširuje túto hranicu na každého lokálneho používateľa. To je zámerné rozšírenie prístupu, nie obchádzka pre automatizáciu.

Nechajte spúšťač konať v rovnakom kontexte relácie

Nechajte podporovanú integráciu udalostí VPN požiadať o spustenie akcie používateľskej relácie, namiesto predpokladu, že privilegovaný callback si môže požičať prihlasovací údaj pracovnej plochy. Obmedzte spúšťač na zamýšľaný identifikátor pripojenia, nie na akékoľvek rozhranie, ktoré sa náhodou volá tun0. Pravidlo dispečera, ktoré zodpovedá nesprávnej veci, sa spustí pri každej zmene siete, vrátane tých, ktoré s týmto pripojením nemajú nič spoločné.

Akcia by mala potvrdiť očakávané meno hostiteľa, všimnúť si existujúce pripojenie a urobiť jeden obmedzený pokus. Slučka dotazovania, ktorá každých pár sekúnd spustí nový proces SSHFS alebo zopakuje výzvu na prihlásenie, kým je server nedostupný, premení krátky výpadok na kopu zaseknutých procesov. Obmedzte pokus časovým limitom a jedným opakovaním.

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

Prvý príkaz dáva identifikátor pripojenia, ktorému má dispečer zodpovedať. Ďalšie dva ukazujú, či už pokus beží, a to je kontrola, ktorá bráni duplicitám.

Nesledovaná služba potrebuje vlastné schválené prihlasovacie údaje a vlastné overenie hostiteľa vo vlastnom kontexte vykonávania. Nemôže predpokladať, že grafický agent je odomknutý, a nemala by sa ho pokúšať odomknúť.

Naplánujte odpojenie skôr, než vynútite upratovanie

Pri plánovanom odpojení dokončite súborové operácie a odpojte z vlastného pracovného postupu používateľa, ktorý pripája. Cieľte na prípomný bod, nie na proces, a potvrďte výsledok, než nahlásite úspech.

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

Odpojte iba pripojenie, ktoré vytvoril tento pracovný postup. Ak je zaneprázdnené, je to rozhodnutie aplikácie: vynútené odpojenie, ktoré existuje preto, aby hák vrátil úspech, skrýva stratu údajov namiesto toho, aby jej zabránilo.

Neočakávaná strata sa správa inak. SSHFS dokumentuje, že prerušenie siete môže zablokovať operáciu súborového systému, a voľba reconnect obnoví prenos bez obnovenia handle: súbor otvorený pred opätovným pripojením môže pri ďalšom zápise zlyhať a prerušený zápis sa neuchová. Tento rozdiel je najdôležitejší pre editori, ktoré držia jeden súbor otvorený hodiny. Naplánujte krok opätovného otvorenia namiesto spoliehania sa na obnovu.

Otestujte správanie s jednorazovými súbormi, kým sa naň spoľahnete. Adresár, ktorý sa po návrate tunela znova objaví, nedokazuje, že predchádzajúce handle alebo neuložená práca prežili.