A felhasználói munkamenetnek kell birtokolnia a VPN feletti SSHFS-csatolást?

Egy megosztott mappa csatolása a VPN felállása után két identitást érint, amelyeket könnyű összekeverni: a hálózat konfigurálására jogosult komponenst és a fájlszerverre bejelentkezni jogosult fiókot. Ritkán ugyanaz a kettő. A root tulajdonában lévő VPN-hook rossz hely egy asztali felhasználó SSHFS-csatolásának indítására, mert sem a felhasználó ügynökével, sem a szándékolt csatolási tulajdonnal nem rendelkezik. A tulajdon első helyes beállítása egyszerűvé teszi a kiváltót.

Két identitás, két külön engedély

A VPN-kliensnek jogosultságok kellenek az útvonalak és interfészek módosításához. Az SSHFS-csatolásnak a fájlszerver által elfogadott SSH-identitásra és a fájlokat olvasó fiók tulajdonában lévő FUSE-csatolásra van szüksége. Egy rootként futó szkript teljesíti az első követelményt és csendben megszegi a másodikat.

A rootként való csatolás az asztali munkameneten kívül hagyja a fájlokat, és esetleg a felhasználó kulcsát tartó ügynök elérésének lehetősége nélkül. A csatolás létezik, a felhasználó nem tud rajta keresztül írni, és a hiba szerveroldali engedélyproblémának tűnik. Ez a téves diagnózis egy délutánba és egy jegybe kerül a tárolócsapatnál.

Döntse el, melyik fiók birtokolja a csatolást, mielőtt bármilyen automatizálást ír, mert ez a választás határozza meg, hol él a kiváltó és milyen hitelesítő adatokat érhet el.

Először kézzel hozzon létre felhasználói tulajdonú csatolást

Induljon egy bejelentkezett felhasználóból üres csatolási ponttal, engedélyezett SSH-fiókkal és a szerverhez vezető működő útvonallal az alagúton keresztül. A kézi csatolás megteremti azt az alapot, amelyet minden automatizálásnak reprodukálnia kell.

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

A nevek példák, ezért cserélje ki a hosztot és az exportútvonalat, amelyet a szervere valóban kínál. Ellenőrizze a hosztkulcsot a jóváhagyott folyamaton keresztül az első kapcsolatnál. Vegye figyelembe, hogy a VPN-fiók jelszava nem automatikusan a tárolófiók hitelesítő adata, és ez a sikertelen kísérletek gyakori oka.

Futtassa normál felhasználóként egy olyan csatolási ponttal, amely az adott felhasználó tulajdonában van. Alapértelmezés szerint csak a csatoló fiók éri el a fájlokat, és az allow_other ezt a határt minden helyi felhasználóra kiterjeszti. Ez a hozzáférés szándékos kiterjesztése, nem megkerülő megoldás az automatizáláshoz.

Hagyja, hogy a kiváltó ugyanabban a munkamenet-kontextusban működjön

Hagyja, hogy a támogatott VPN-eseményintegráció felhasználói munkamenet-művelet futtatását kérje, ahelyett hogy feltételezné, hogy egy kiváltságos callback kölcsönözhet asztali hitelesítő adatot. Korlátozza a kiváltót a szándékolt kapcsolatazonosítóra, ne bármely interfészre, amelyet véletlenül tun0-nak hívnak. A rossz dologra illeszkedő diszpécserszabály minden hálózati változásnál elsül, beleértve azokat is, amelyeknek semmi közük ehhez a csatoláshoz.

A műveletnek meg kell erősítenie a várt hosztnevet, észre kell vennie egy meglévő csatolást, és egy korlátozott kísérletet kell tennie. Egy lekérdező hurok, amely néhány másodpercenként új SSHFS-folyamatot indít, vagy megismétli a hitelesítő adat kérését, miközben a szerver áll, egy rövid kiesést elakadt folyamatok halmazává változtat. Korlátozza a kísérletet időtúllépéssel és egyetlen újrapróbálkozással.

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

Az első parancs adja a kapcsolatazonosítót, amelyre a diszpécsernek illeszkednie kell. A másik kettő megmutatja, fut-e már kísérlet, és ez az a ellenőrzés, amely megakadályozza a duplikátumokat.

Egy felügyelet nélküli szolgáltatásnak saját jóváhagyott hitelesítő adatokra és saját hosztellenőrzésre van szüksége a saját végrehajtási kontextusában. Nem feltételezheti, hogy egy grafikus ügynök fel van oldva, és nem is szabadna megpróbálnia feloldani egyet.

Tervezze meg a leválasztást, mielőtt kényszeríti a tisztítást

Tervezett leválasztás esetén fejezze be a fájlműveleteket, és a csatoló felhasználó saját munkafolyamatából válassza le. A folyamat helyett a csatolási pontot célozza, és erősítse meg az eredményt, mielőtt sikert jelent.

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

Csak azt a csatolást válassza le, amelyet ez a munkafolyamat hozott létre. Ha foglalt, az az alkalmazás döntése: egy kényszerített leválasztás, amely csak azért létezik, hogy egy hook sikert adjon vissza, elrejti az adatvesztést ahelyett, hogy megelőzné.

A váratlan veszteség másképp viselkedik. Az SSHFS dokumentálja, hogy egy hálózati megszakítás blokkolhat egy fájlrendszer-műveletet, és a reconnect opció helyreállítja az átvitelt a fogantyúk helyreállítása nélkül: egy újracsatlakozás előtt megnyitott fájl a következő írásnál meghiúsulhat, és a megszakított írás nem marad meg. Ez a különbség a legfontosabb azoknak a szerkesztőknek, amelyek órákig nyitva tartanak egy fájlt. Tervezzen újranyitási lépést ahelyett, hogy helyreállítást feltételezne.

Tesztelje a viselkedést eldobható fájlokkal, mielőtt támaszkodna rá. Egy könyvtár, amely újra megjelenik az alagút visszatérése után, nem bizonyítja, hogy a korábbi fogantyúk vagy a nem mentett munka túlélték.