Ar trebui ca sesiunea utilizatorului să dețină montarea SSHFS prin VPN?

Montarea unui folder partajat după ce VPN-ul pornește implică două identități ușor de confundat: componenta autorizată să configureze rețeaua și contul autorizat să se conecteze la serverul de fișiere. Rar sunt aceeași. Un hook VPN deținut de root este un loc prost pentru a începe montarea SSHFS a unui utilizator de desktop, deoarece nu are nici agentul utilizatorului, nici proprietatea de montare prevăzută. Stabilirea corectă a proprietății mai întâi face declanșatorul simplu.

Două identități, două permisiuni separate

Clientul VPN are nevoie de privilegii pentru a schimba rute și interfețe. Montarea SSHFS are nevoie de o identitate SSH acceptată de serverul de fișiere și de o montare FUSE deținută de contul care va citi fișierele. Un singur script rulat ca root îndeplinește prima cerință și încalcă în tăcere a doua.

Montarea ca root lasă fișierele în afara sesiunii desktop și posibil fără acces la agentul care păstrează cheia utilizatorului. Montarea există, utilizatorul nu poate scrie prin ea, iar eșecul arată ca o problemă de permisiuni pe partea serverului. Acel diagnostic greșit costă o după-amiază și un tichet către echipa de stocare.

Decideți ce cont deține montarea înainte de a scrie orice automatizare, deoarece această alegere determină unde trăiește declanșatorul și la ce acreditări poate ajunge.

Mai întâi stabiliți manual o montare deținută de utilizator

Începeți cu un utilizator conectat cu un punct de montare gol, un cont SSH autorizat și o cale funcțională către server prin tunel. O montare manuală stabilește linia de bază pe care orice automatizare trebuie să o reproducă.

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

Numele sunt exemple, așa că înlocuiți gazda și calea de export pe care serverul dumneavoastră le oferă de fapt. Verificați cheia gazdei prin procesul aprobat la acea primă conexiune. Rețineți că parola contului VPN nu este automat acreditarea contului de stocare, iar aceasta este o cauză frecventă a încercărilor eșuate.

Rulați-l ca utilizator obișnuit cu un punct de montare deținut de acel utilizator. În mod implicit, doar contul care montează ajunge la fișiere, iar allow_other extinde această graniță la fiecare utilizator local. Aceasta este o extindere deliberată a accesului, nu o soluție ocolitoare pentru automatizare.

Lăsați declanșatorul să acționeze în același context de sesiune

Lăsați integrarea de evenimente VPN acceptată să ceară executarea unei acțiuni a sesiunii utilizatorului, în loc să presupunem că un callback privilegiat poate împrumuta o acreditare de desktop. Limitați declanșatorul la identificatorul de conexiune prevăzut și nu la orice interfață care se numește din întâmplare tun0. O regulă de dispecer care corespunde lucrului greșit se declanșează la fiecare schimbare de rețea, inclusiv la cele care nu au nimic de-a face cu această montare.

Acțiunea ar trebui să confirme numele de gazdă așteptat, să observe o montare existentă și să facă o singură încercare limitată. O buclă de interogare care pornește un proces SSHFS nou la fiecare câteva secunde sau repetă o cerere de acreditări cât timp serverul este oprit transformă o întrerupere scurtă într-o grămadă de procese blocate. Limitați încercarea cu un timeout și o singură reîncercare.

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

Prima comandă oferă identificatorul de conexiune cu care dispecerul trebuie să corespundă. Celelalte două arată dacă o încercare este deja în curs, iar aceasta este verificarea care previne duplicatele.

Un serviciu nesupravegheat are nevoie de propriile acreditări aprobate și de propria verificare a gazdei în propriul context de execuție. Nu poate presupune că un agent grafic este deblocat și nu ar trebui să încerce să deblocheze unul.

Planificați deconectarea înainte de a forța curățarea

Pentru o deconectare planificată, finalizați operațiunile cu fișiere și demontați din propriul flux de lucru al utilizatorului care montează. Țintiți punctul de montare, nu procesul, și confirmați rezultatul înainte de a raporta succes.

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

Demontați doar montarea creată de acest flux de lucru. Dacă este ocupată, este o decizie a aplicației: o detașare forțată care există pentru ca un hook să returneze succes ascunde pierderea de date în loc să o prevină.

Pierderea neașteptată se comportă diferit. SSHFS documentează că o întrerupere de rețea poate bloca o operațiune a sistemului de fișiere, iar opțiunea reconnect restaurează transportul fără a restaura handle-urile: un fișier deschis înainte de reconectare poate eșua la următoarea scriere, iar o scriere întreruptă nu este păstrată. Această distincție contează cel mai mult pentru editorii care țin un fișier deschis ore întregi. Planificați un pas de redeschidere în loc să presupuneți recuperarea.

Testați comportamentul cu fișiere de unică folosință înainte de a vă baza pe el. Un director care reapare după ce tunelul revine nu dovedește că handle-urile anterioare sau lucrul nesalvat au supraviețuit.