Pitäisikö käyttäjäistunnon omistaa SSHFS-liitoksen VPN:n yli?

Jaetun kansion liittäminen VPN:n noustua koskee kahta identiteettiä, jotka on helppo sekoittaa: komponentti, jolla on lupa määrittää verkko, ja tili, jolla on lupa kirjautua tiedostopalvelimeen. Ne ovat harvoin sama. Rootin omistama VPN-koukku on huono paikka aloittaa työpöytäkäyttäjän SSHFS-liitos, koska sillä ei ole käyttäjän agenttia eikä aiottua liitoksen omistajuutta. Kun omistajuus on ensin oikein, liipaisimesta tulee yksinkertainen.

Kaksi identiteettiä, kaksi erillistä lupaa

VPN-asiakas tarvitsee oikeudet reittien ja liitäntöjen muuttamiseen. SSHFS-liitos tarvitsee SSH-identiteetin, jonka tiedostopalvelin hyväksyy, ja FUSE-liitoksen, jonka omistaa tili, joka lukee tiedostot. Yksi rootina ajettava skripti täyttää ensimmäisen vaatimuksen ja rikkoo hiljaa toisen.

Rootina liittäminen jättää tiedostot työpöytäistunnon ulkopuolelle ja mahdollisesti ilman pääsyä agenttiin, joka pitää käyttäjän avainta. Liitos on olemassa, käyttäjä ei voi kirjoittaa sen kautta, ja vika näyttää palvelinpuolen käyttöoikeusongelmalta. Tämä väärä diagnoosi maksaa iltapäivän ja tiketin tallennustiimille.

Päätä, mikä tili omistaa liitoksen, ennen kuin kirjoitat mitään automaatiota, koska tämä valinta määrää, missä liipaisin elää ja mihin tunnistetietoihin se voi päästä.

Perusta ensin käsin käyttäjän omistama liitos

Aloita kirjautuneesta käyttäjästä, jolla on tyhjä liitospiste, valtuutettu SSH-tili ja toimiva polku palvelimelle tunnelin kautta. Manuaalinen liitos luo perustan, joka jokaisen automaation on toistettava.

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

Nimet ovat esimerkkejä, joten korvaa isäntänimi ja vientipolku, jotka palvelimesi todella tarjoaa. Vahvista isännän avain hyväksytyllä prosessilla tuolla ensimmäisellä yhteydellä. Huomaa, että VPN-tilin salasana ei ole automaattisesti tallennustilin tunnistetieto, ja se on yleinen syy epäonnistuneisiin yrityksiin.

Aja se tavallisena käyttäjänä liitospisteellä, jonka kyseinen käyttäjä omistaa. Oletuksena vain liittävä tili pääsee tiedostoihin, ja allow_other laajentaa tämän rajan jokaiseen paikalliseen käyttäjään. Se on tarkoituksellinen pääsyn laajennus, ei kiertotie automaatiolle.

Anna liipaisimen toimia samassa istuntokontekstissa

Anna tuetun VPN-tapahtumaintegraation pyytää käyttäjäistunnon toimintoa suoritettavaksi sen sijaan, että oletettaisiin privilegioidun callbackin voivan lainata työpöydän tunnistetietoja. Rajaa liipaisin aiottuun yhteyden tunnisteeseen eikä mihin tahansa liitäntään, joka sattuu olemaan nimeltään tun0. Dispatcher-sääntö, joka osuu väärään asiaan, laukeaa jokaisella verkkomuutoksella, myös niillä, joilla ei ole mitään tekemistä tämän liitoksen kanssa.

Toiminnon tulisi vahvistaa odotettu isäntänimi, huomata olemassa oleva liitos ja tehdä yksi rajattu yritys. Kyselysilmukka, joka käynnistää uuden SSHFS-prosessin muutaman sekunnin välein tai toistaa tunnistetietopyyntöä palvelimen ollessa alhaalla, muuttaa lyhyen katkoksen joukoksi jumiutuneita prosesseja. Rajaa yritys aikakatkaisulla ja yhdellä uudelleenyrityksellä.

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

Ensimmäinen komento antaa yhteyden tunnisteen, johon dispatcherin pitäisi osua. Kaksi muuta näyttävät, onko yritys jo käynnissä, ja se on tarkistus, joka estää kopiot.

Valvomaton palvelu tarvitsee omat hyväksytyt tunnistetietonsa ja oman isäntävahvistuksensa omassa suorituskontekstissaan. Se ei voi olettaa graafisen agentin olevan lukitsematta, eikä sen pitäisi yrittää avata sellaista.

Suunnittele irrotus ennen kuin pakotat siivouksen

Suunnitellussa irrotuksessa viimeistele tiedostotoiminnot ja irrota liittävän käyttäjän omasta työnkulusta. Kohdista liitospisteeseen eikä prosessiin, ja vahvista tulos ennen kuin ilmoitat onnistumisesta.

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

Irrota vain liitos, jonka tämä työnkulku loi. Jos se on varattu, se on sovelluksen päätös: pakotettu irrotus, joka on olemassa vain saadakseen koukun palauttamaan onnistumisen, piilottaa tietohäviön sen estämisen sijaan.

Odottamaton häviö käyttäytyy eri tavalla. SSHFS dokumentoi, että verkkokatkos voi estää tiedostojärjestelmätoiminnon, ja reconnect-vaihtoehto palauttaa siirron palauttamatta kahvoja: ennen uudelleenyhdistämistä avattu tiedosto voi epäonnistua seuraavassa kirjoituksessa, eikä keskeytynyttä kirjoitusta säilytetä. Tämä ero on tärkein editoreille, jotka pitävät yhtä tiedostoa auki tunteja. Suunnittele uudelleenavausvaihe sen sijaan, että olettaisit palautumisen.

Testaa käyttäytymistä kertakäyttöisillä tiedostoilla ennen kuin luotat siihen. Hakemisto, joka ilmestyy uudelleen tunnelin palattua, ei todista, että aiemmat kahvat tai tallentamaton työ säilyivät.