Má uživatelská relace vlastnit SSHFS připojení přes VPN?

Připojení sdílené složky po spuštění VPN zahrnuje dvě identity, které lze snadno zaměnit: komponentu, která smí konfigurovat síť, a účet, který se smí přihlásit k souborovému serveru. Zřídka jsou stejné. VPN hook vlastněný rootem je špatné místo pro zahájení SSHFS připojení uživatele pracovní plochy, protože nemá ani agenta uživatele, ani zamýšlené vlastnictví připojení. Když se vlastnictví nastaví správně jako první, spouštěč je jednoduchý.

Dvě identity, dvě oddělená oprávnění

Klient VPN potřebuje oprávnění měnit trasy a rozhraní. SSHFS připojení potřebuje identitu SSH, kterou souborový server přijme, a připojení FUSE vlastněné účtem, který bude soubory číst. Jeden skript spuštěný jako root splní první požadavek a tiše poruší druhý.

Připojení jako root nechává soubory mimo relaci pracovní plochy a možná bez přístupu k agentovi, který drží klíč uživatele. Připojení existuje, uživatel přes něj nemůže zapisovat a selhání vypadá jako problém s oprávněními na straně serveru. Tato chybná diagnóza stojí odpoledne a tiket pro tým úložiště.

Rozhodněte, který účet připojení vlastní, dřív než napíšete jakoukoli automatizaci, protože tato volba určuje, kde spouštěč žije a ke kterým přihlašovacím údajům se může dostat.

Nejprve ručně vytvořte připojení vlastněné uživatelem

Začněte s přihlášeným uživatelem s prázdným přípojným bodem, autorizovaným účtem SSH a funkční cestou k serveru přes tunel. Ruční připojení stanoví základ, který musí každá automatizace reprodukovat.

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

Názvy jsou příklady, takže nahraďte hostitele a exportní cestu, které váš server skutečně nabízí. Ověřte klíč hostitele schváleným postupem při tomto prvním připojení. Všimněte si, že heslo účtu VPN není automaticky přihlašovacím údajem účtu úložiště, což je častá příčina neúspěšných pokusů.

Spusťte ho jako běžný uživatel s přípojným bodem, který tomuto uživateli patří. Ve výchozím nastavení se k souborům dostane jen účet, který připojuje, a allow_other rozšiřuje tuto hranici na každého místního uživatele. To je záměrné rozšíření přístupu, ne obchvat pro automatizaci.

Nechte spouštěč jednat ve stejném kontextu relace

Nechte podporovanou integraci událostí VPN požádat o spuštění akce uživatelské relace, místo abyste předpokládali, že privilegovaný callback si může půjčit přihlašovací údaj pracovní plochy. Omezte spouštěč na zamýšlený identifikátor připojení, ne na jakékoli rozhraní, které se náhodou jmenuje tun0. Pravidlo dispečera, které odpovídá špatné věci, se spustí při každé změně sítě, včetně těch, které s tímto připojením nemají nic společného.

Akce by měla potvrdit očekávané jméno hostitele, všimnout si existujícího připojení a provést jeden omezený pokus. Smyčka dotazování, která každých pár sekund spouští nový proces SSHFS nebo opakuje výzvu k přihlášení, dokud je server nedostupný, promění krátký výpadek v hromadu zaseknutých procesů. Omezte pokus časovým limitem a jedním opakováním.

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

První příkaz dává identifikátor připojení, kterému má dispečer odpovídat. Další dva ukazují, zda už pokus běží, a to je kontrola, která brání duplicitám.

Nesledovaná služba potřebuje vlastní schválené přihlašovací údaje a vlastní ověření hostitele ve vlastním kontextu provádění. Nemůže předpokládat, že je grafický agent odemčený, a neměla by se ho pokoušet odemknout.

Naplánujte odpojení dřív, než vynutíte úklid

Při plánovaném odpojení dokončete souborové operace a odpojte z vlastního pracovního postupu uživatele, který připojuje. Cilte na přípojný bod, ne na proces, a potvrďte výsledek, než nahlásíte úspěch.

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

Odpojte jen připojení, které vytvořil tento pracovní postup. Pokud je zaneprázdněné, je to rozhodnutí aplikace: vynucené odpojení, které existuje proto, aby hook vrátil úspěch, skrývá ztrátu dat místo aby jí zabránilo.

Neočekávaná ztráta se chová jinak. SSHFS dokumentuje, že přerušení sítě může zablokovat operaci souborového systému, a volba reconnect obnoví přenos bez obnovení handle: soubor otevřený před opětovným připojením může při dalším zápisu selhat a přerušený zápis se neuchová. Tento rozdíl je nejdůležitější pro editory, které drží jeden soubor otevřený hodiny. Naplánujte krok opětovného otevření místo spoléhání na obnovu.

Chování otestujte s jednorázovými soubory, než se na něj spolehnete. Adresář, který se po návratu tunelu znovu objeví, nedokazuje, že dřívější handle nebo neuložená práce přežily.