Трябва ли потребителската сесия да притежава SSHFS монтирането през VPN?

Монтирането на споделена папка след вдигане на VPN включва две идентичности, които лесно се объркват: компонентът, на който е разрешено да конфигурира мрежата, и акаунтът, на който е разрешено да влиза във файловия сървър. Те рядко съвпадат. VPN hook под 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"

Демонтирайте само монтирането, което този работен процес е създал. Ако е заето, това е решение на приложението: принудителното отделяне, което съществува, за да върне успех на hook, скрива загуба на данни, вместо да я предотвратява.

Неочакваната загуба се държи различно. SSHFS документира, че прекъсване на мрежата може да блокира операция на файловата система, а опцията reconnect възстановява транспорта, без да възстановява манипулатори: файл, отворен преди повторното свързване, може да се провали при следващия запис, а прекъснатият запис не се запазва. Тази разлика е най-важна за редактори, които държат един файл отворен с часове. Планирайте стъпка за повторно отваряне, вместо да приемате възстановяване.

Тествайте поведението с файлове за еднократна употреба, преди да разчитате на него. Папка, която се появява отново след връщането на тунела, не доказва, че предишните манипулатори или незапазената работа са оцелели.