Bör användarsessionen äga SSHFS-monteringen över VPN?

Montering av en delad mapp efter att VPN:en kommit upp innebär två identiteter som är lätta att förväxla: komponenten som får konfigurera nätverket och kontot som får logga in på filservern. De är sällan samma. En rootägd VPN-krok är en dålig plats att starta en skrivbordsanvändares SSHFS-montering, eftersom den varken har användarens agent eller det avsedda monteringsägandet. När ägandet först är rätt blir utlösaren enkel.

Två identiteter, två separata behörigheter

VPN-klienten behöver privilegier för att ändra rutter och gränssnitt. SSHFS-monteringen behöver en SSH-identitet som filservern accepterar och en FUSE-montering som ägs av kontot som ska läsa filerna. Ett skript som körs som root uppfyller det första kravet och bryter tyst det andra.

Montering som root lämnar filerna utanför skrivbordssessionen och möjligen utan åtkomst till agenten som håller användarens nyckel. Montering finns, användaren kan inte skriva genom den, och felet ser ut som ett behörighetsproblem på serversidan. Den feldiagnosen kostar en eftermiddag och en biljett till lagringsteamet.

Bestäm vilket konto som äger monteringen innan du skriver någon automatisering, eftersom det valet avgör var utlösaren bor och vilka autentiseringsuppgifter den kan nå.

Upprätta först en användarägd montering manuellt

Börja med en inloggad användare med en tom monteringspunkt, ett auktoriserat SSH-konto och en fungerande sökväg till servern genom tunneln. En manuell montering fastställer den baslinje som varje automatisering måste återskapa.

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

Namnen är exempel, så ersätt värden och exportsökvägen som din server faktiskt erbjuder. Verifiera värdnyckeln genom den godkända processen vid den första anslutningen. Observera att ett VPN-kontolösenord inte automatiskt är lagringskontots autentiseringsuppgift, och det är en vanlig orsak till misslyckade försök.

Kör det som en vanlig användare med en monteringspunkt som den användaren äger. Som standard är det bara kontot som monterar som når filerna, och allow_other utökar den gränsen till varje lokal användare. Det är en avsiktlig utökning av åtkomsten, inte en omväg för automatisering.

Låt utlösaren agera i samma sessionskontext

Låt den stödda VPN-händelseintegrationen begära att en användarsessionsåtgärd körs, i stället för att anta att en privilegierad callback kan låna en skrivbordsautentisering. Begränsa utlösaren till den avsedda anslutningsidentifieraren i stället för till vilket gränssnitt som helst som råkar heta tun0. En dispatcher-regel som matchar fel sak utlöses vid varje nätverksändring, även de som inte har något med den här monteringen att göra.

Åtgärden bör bekräfta det förväntade värdnamnet, lägga märke till en befintlig montering och göra ett begränsat försök. En avfrågningsslinga som startar en ny SSHFS-process varannan sekund, eller upprepar en begäran om autentiseringsuppgifter medan servern är nere, förvandlar ett kort avbrott till en hög med fastnade processer. Begränsa försöket med en timeout och ett enda nytt försök.

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

Det första kommandot ger anslutningsidentifieraren som dispatchern ska matcha. De två andra visar om ett försök redan pågår, och det är kontrollen som förhindrar dubbletter.

En oövervakad tjänst behöver sina egna godkända autentiseringsuppgifter och sin egen värdverifiering i sin egen körningskontext. Den kan inte anta att en grafisk agent är upplåst, och den bör inte försöka låsa upp en.

Planera frånkopplingen innan du tvingar fram städningen

Vid en planerad frånkoppling, slutför filoperationerna och avmontera från den monterande användarens eget arbetsflöde. Rikta in dig på monteringspunkten i stället för processen, och bekräfta resultatet innan du rapporterar framgång.

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

Avmontera bara den montering som detta arbetsflöde skapade. Om den är upptagen är det ett beslut i programmet: en påtvingad frånkoppling som finns för att få en krok att returnera framgång döljer dataförlust i stället för att förhindra den.

Oväntad förlust beter sig annorlunda. SSHFS dokumenterar att ett nätverksavbrott kan blockera en filsystemoperation, och alternativet reconnect återställer transporten utan att återställa handtag: en fil som öppnades före återanslutningen kan misslyckas vid nästa skrivning, och en avbruten skrivning bevaras inte. Den skillnaden är viktigast för redigerare som håller en fil öppen i timmar. Planera ett steg för att öppna igen i stället för att anta återställning.

Testa beteendet med engångsfiler innan du förlitar dig på det. En mapp som dyker upp igen efter att tunneln återvänder bevisar inte att tidigare handtag eller osparat arbete överlevde.