Dapat bang pagmamay-ari ng session ng user ang SSHFS mount sa VPN?

Ang pag-mount ng shared folder pagkatapos bumangon ang VPN ay may kasamang dalawang identidad na madaling pagkamalan: ang component na pinapayagang i-configure ang network, at ang account na pinapayagang mag-log in sa file server. Bihirang magkapareho sila. Ang root-owned VPN hook ay masamang lugar para simulan ang SSHFS mount ng desktop user, dahil wala itong agent ng user o ang nilalayong pagmamay-ari ng mount. Ang pagtama muna sa pagmamay-ari ay nagpapasimple sa trigger.

Dalawang identidad, dalawang hiwalay na pahintulot

Kailangan ng VPN client ng mga pribilehiyo para baguhin ang mga ruta at interface. Kailangan ng SSHFS mount ng SSH identity na tinatanggap ng file server at FUSE mount na pagmamay-ari ng account na magbabasa ng mga file. Isang script na tumatakbo bilang root ang tumutupad sa unang pangangailangan at tahimik na sumisira sa pangalawa.

Ang pag-mount bilang root ay nag-iiwan ng mga file sa labas ng desktop session at posibleng walang access sa agent na may hawak ng key ng user. Umiiral ang mount, hindi makapagsulat ang user sa pamamagitan nito, at ang pagkabigo ay mukhang problema sa pahintulot sa panig ng server. Ang maling diagnosis na iyon ay nagkakahalaga ng isang hapon at isang ticket sa storage team.

Magpasya kung aling account ang nagmamay-ari ng mount bago magsulat ng anumang automation, dahil tinutukoy ng pagpipiliang iyon kung saan nakatira ang trigger at kung aling mga kredensyal ang maaabot nito.

Magtatag muna ng user-owned mount sa pamamagitan ng kamay

Magsimula sa isang naka-sign in na user na may walang laman na mountpoint, awtorisadong SSH account at gumaganang path sa server sa pamamagitan ng tunnel. Ang manual na mount ay nagtatatag ng baseline na dapat kopyahin ng anumang automation.

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

Ang mga pangalan ay mga halimbawa, kaya palitan ang host at export path na aktwal na inaalok ng iyong server. I-verify ang host key sa pamamagitan ng aprubadong proseso sa unang koneksyong iyon. Tandaan na ang password ng VPN account ay hindi awtomatikong kredensyal ng storage account, at iyon ay karaniwang dahilan ng mga nabigong pagtatangka.

Patakbuhin ito bilang normal na user na may mountpoint na pagmamay-ari ng user na iyon. Bilang default, ang account na nag-mount lang ang nakakaabot sa mga file, at pinalalawak ng allow_other ang hangganang iyon sa bawat lokal na user. Iyon ay sadyang pagpapalawak ng access, hindi isang paraan ng pag-iwas para sa automation.

Hayaang kumilos ang trigger sa parehong konteksto ng session

Hayaang hilingin ng sinusuportahang VPN event integration na tumakbo ang isang user-session action, sa halip na ipagpalagay na makakahiram ng desktop credential ang isang privileged callback. Limitahan ang trigger sa nilalayong connection identifier at hindi sa anumang interface na nagkataong tinatawag na tun0. Ang dispatcher rule na tumutugma sa maling bagay ay pumaputok sa bawat pagbabago ng network, kabilang ang mga walang kinalaman sa mount na ito.

Dapat kumpirmahin ng aksyon ang inaasahang hostname, mapansin ang umiiral na mount, at gumawa ng isang limitadong pagtatangka. Ang poll loop na nagsisimula ng bagong SSHFS process tuwing ilang segundo, o inuulit ang credential prompt habang down ang server, ay ginagawang tumpok ng stuck process ang maikling outage. Limitahan ang pagtatangka sa isang timeout at isang retry.

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

Ibinibigay ng unang command ang connection identifier na dapat itugma ng dispatcher. Ipinapakita ng dalawa pa kung may tumatakbong pagtatangka, at iyon ang check na pumipigil sa duplicates.

Kailangan ng unattended service ang sarili nitong aprubadong kredensyal at sarili nitong host verification sa sarili nitong execution context. Hindi nito maipagpalagay na naka-unlock ang isang graphical agent, at hindi ito dapat magtangkang i-unlock ang isa.

Planuhin ang disconnect bago pilitin ang cleanup

Para sa planadong disconnect, tapusin ang mga file operation at mag-unmount mula sa sariling workflow ng user na nag-mount. I-target ang mountpoint at hindi ang process, at kumpirmahin ang resulta bago mag-ulat ng tagumpay.

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

I-unmount lamang ang mount na ginawa ng workflow na ito. Kung abala ito, desisyon iyon ng application: ang forced detach na umiiral para makapagbalik ng tagumpay ang isang hook ay nagtatago ng data loss sa halip na pigilan ito.

Iba ang kilos ng hindi inaasahang pagkawala. Itinatala ng SSHFS na ang pagkagambala sa network ay maaaring humarang sa isang filesystem operation, at ibinabalik ng reconnect option ang transport nang hindi ibinabalik ang mga handle: ang file na binuksan bago ang reconnect ay maaaring mabigo sa susunod na write, at ang naantalang write ay hindi pinapanatili. Ang pagkakaibang iyon ang pinakamahalaga para sa mga editor na nag-iiwan ng isang file na bukas nang ilang oras. Planuhin ang hakbang ng muling pagbubukas sa halip na ipagpalagay ang pagbawi.

Subukan ang kilos gamit ang mga disposable file bago umasa dito. Ang direktoryo na muling lumilitaw pagkatapos bumalik ang tunnel ay hindi nagpapatunay na ang mga naunang handle o hindi na-save na trabaho ay nakaligtas.