Ці павінна карыстальніцкая сесія валодаць кропкай мантавання SSHFS праз VPN?

Мантаванне агульнай папкі пасля ўздыму VPN закранае дзве асобы, якія лёгка зблытаць: кампанент, якому дазволена наладжваць сетку, і ўліковы запіс, якому дазволена ўваходзіць на файлавы сервер. Яны рэдка супадаюць. VPN-хук ва ўласнасці root — дрэннае месца для пачатку мантавання SSHFS карыстальніка працоўнага стала, бо ён не мае ні агента карыстальніка, ні меркаванага ўладальніка мантавання. Калі спачатку правільна вызначыць уласнасць, трыгер становіцца простым.

Дзве асобы, два асобныя дазволы

Кліенту VPN патрэбны прывілеі для змены маршрутаў і інтэрфейсаў. Мантаванню SSHFS патрэбна асоба SSH, якую прымае файлавы сервер, і мантаванне FUSE, якое належыць уліковаму запісу, што будзе чытаць файлы. Адзін скрыпт пад root задавальняе першае патрабаванне і ціха ламае другое.

Мантаванне пад root пакідае файлы па-за сесіяй працоўнага стала і, магчыма, без доступу да агента, які трымае ключ карыстальніка. Мантаванне існуе, карыстальнік не можа пісаць праз яго, і збой выглядае як праблема правоў на баку сервера. Такі памылковы дыягназ каштуе паўдня і тыкета камандзе сховішча.

Вызначце, які ўліковы запіс валодае мантаваннем, перш чым пісаць любую аўтаматызацыю, бо гэты выбар вызначае, дзе жыве трыгер і да якіх уліковых даных ён можа дабрацца.

Спачатку стварыце мантаванне ва ўласнасці карыстальніка ўручную

Пачніце з увайшоўшага карыстальніка з пустой кропкай мантавання, аўтарызаваным уліковым запісам SSH і працоўным шляхам да сервера праз тунель. Ручное мантаванне ўстанаўлівае базу, якую павінна паўтарыць любая аўтаматызацыя.

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

Імёны — прыклады, таму заменіце хост і шлях экспарту, якія ваш сервер сапраўды прапануе. Праверце ключ хоста праз ухвалены працэс пры першым злучэнні. Звярніце ўвагу, што пароль уліковага запісу VPN не з’яўляецца аўтаматычна ўліковымі данымі сховішча, і гэта частая прычына няўдалых спробаў.

Запусціце яго як звычайны карыстальнік з кропкай мантавання, якой валодае гэты карыстальнік. Па змаўчанні толькі ўліковы запіс, што мантуе, дабіраецца да файлаў, а allow_other пашырае гэтую мяжу на кожнага лакальнага карыстальніка. Гэта наўмыснае пашырэнне доступу, а не абыход для аўтаматызацыі.

Няхай трыгер дзейнічае ў тым жа кантэксце сесіі

Няхай падтрыманая інтэграцыя падзей VPN папросіць выканаць дзеянне карыстальніцкай сесіі, замест таго каб меркаваць, што прывілеяваны callback можа пазычыць уліковыя даныя працоўнага стала. Абмяжуйце трыгер меркаваным ідэнтыфікатарам злучэння, а не любым інтэрфейсам, які выпадкова называецца tun0. Правіла дыспетчара, што супадае з не тым, спрацоўвае пры кожнай змене сеткі, у тым ліку пры тых, што не маюць дачынення да гэтага мантавання.

Дзеянне павінна пацвердзіць чаканае імя хоста, заўважыць існуючае мантаванне і зрабіць адну абмежаваную спробу. Цыкл апытання, які запускае новы працэс SSHFS кожныя некалькі секунд або паўтарае запыт уліковых даных, пакуль сервер не працуе, ператварае кароткі збой у кучу завіслых працэсаў. Абмяжуйце спробу тайм-аўтам і адным паўторам.

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

Першая каманда дае ідэнтыфікатар злучэння, з якім павінен супадаць дыспетчар. Дзве іншыя паказваюць, ці ўжо ідзе спроба, і гэта праверка, якая прадухіляе дублікаты.

Сэрвісу без нагляду патрэбны ўласныя ўхваленыя ўліковыя даныя і ўласная праверка хоста ў яго ўласным кантэксце выканання. Ён не можа меркаваць, што графічны агент разблакіраваны, і не павінен спрабаваць яго разблакіраваць.

Сплануйце адключэнне, перш чым прымусіць ачыстку

Пры планаваным адключэнні скончыце аперацыі з файламі і адмантуйце з уласнага працэсу карыстальніка, што мантуе. Нацэльвайцеся на кропку мантавання, а не на працэс, і пацвердзіце вынік, перш чым паведамляць пра поспех.

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

Адмантуйце толькі тое мантаванне, якое стварыў гэты працэс. Калі яно занята, гэта рашэнне праграмы: прымусовае ад’яднанне, якое існуе, каб хук вярнуў поспех, хавае страту даных замест таго каб прадухіліць яе.

Нечаканая страта паводзіць сябе інакш. SSHFS дакументуе, што перапынак сеткі можа заблакаваць аперацыю файлавай сістэмы, а опцыя reconnect аднаўляе транспарт без аднаўлення дэскрыптараў: файл, адкрыты да перападключэння, можа не запісацца наступным разам, а перарваны запіс не захоўваецца. Гэтая розніца найбольш важная для рэдактараў, якія трымаюць адзін файл адкрытым гадзінамі. Сплануйце крок паўторнага адкрыцця замест таго каб спадзявацца на аднаўленне.

Праверце паводзіны на аднаразовых файлах, перш чым спадзявацца на іх. Папка, якая зноў з’яўляецца пасля вяртання тунеля, не даказвае, што ранейшыя дэскрыптары або незахаваная праца захаваліся.