Debe a sesión de usuario posuír a montaxe SSHFS sobre VPN?

Montar un cartafol compartido despois de que a VPN suba implica dúas identidades que é doado confundir: o compoñente autorizado a configurar a rede e a conta autorizada a iniciar sesión no servidor de ficheiros. Raramente son a mesma. Un hook de VPN propiedade de root é un mal lugar para iniciar a montaxe SSHFS dun usuario de escritorio, porque non ten nin o axente do usuario nin a propiedade de montaxe prevista. Acertar primeiro coa propiedade fai que o gatillo sexa simple.

Dúas identidades, dous permisos separados

O cliente VPN necesita privilexios para cambiar rutas e interfaces. A montaxe SSHFS necesita unha identidade SSH que o servidor de ficheiros acepte e unha montaxe FUSE propiedade da conta que lerá os ficheiros. Un só script executado como root satisfai o primeiro requisito e rompe en silencio o segundo.

Montar como root deixa os ficheiros fóra da sesión de escritorio e posiblemente sen acceso ao axente que garda a chave do usuario. A montaxe existe, o usuario non pode escribir a través dela e o fallo parece un problema de permisos do servidor. Ese diagnóstico erróneo custa unha tarde e un tícket ao equipo de almacenamento.

Decida que conta posúe a montaxe antes de escribir calquera automatización, porque esa elección determina onde vive o gatillo e a que credenciais pode chegar.

Primeiro estableza a man unha montaxe propiedade do usuario

Parta dun usuario que iniciou sesión cun punto de montaxe baleiro, unha conta SSH autorizada e unha ruta funcional ao servidor a través do túnel. Unha montaxe manual establece a liña base que calquera automatización debe reproducir.

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

Os nomes son exemplos, así que substitúa o host e a ruta de exportación que o seu servidor ofrece realmente. Verifique a clave do host mediante o proceso aprobado nesa primeira conexión. Teña en conta que o contrasinal da conta VPN non é automaticamente a credencial da conta de almacenamento, e esa é unha causa habitual de intentos fallidos.

Execúteo como usuario normal cun punto de montaxe propiedade dese usuario. Por defecto, só a conta que monta chega aos ficheiros, e allow_other amplía esa fronteira a cada usuario local. Iso é unha ampliación deliberada do acceso, non unha solución alternativa para a automatización.

Faga que o gatillo actúe no mesmo contexto de sesión

Deixe que a integración de eventos VPN admitida pida executar unha acción da sesión de usuario, en lugar de supor que un callback privilexiado pode tomar prestada unha credencial de escritorio. Limite o gatillo ao identificador de conexión previsto e non a calquera interface que se chame tun0 por casualidade. Unha regra de despachador que coincide co incorrecto actívase en cada cambio de rede, incluídos os que non teñen nada que ver con esta montaxe.

A acción debería confirmar o nome de host esperado, advertir unha montaxe existente e facer un intento acoutado. Un bucle de sondaxe que inicia un novo proceso SSHFS cada poucos segundos, ou reintenta unha petición de credenciais mentres o servidor está caído, converte unha interrupción breve nunha morea de procesos atascados. Limite o intento cun tempo de espera e un só reintento.

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

O primeiro comando dá o identificador de conexión que o despachador debe coincidir. Os outros dous mostran se xa hai un intento en marcha, e esa é a comprobación que evita duplicados.

Un servizo sen supervisión necesita as súas propias credenciais aprobadas e o seu propio mecanismo de verificación de host no seu propio contexto de execución. Non pode supor que un axente gráfico estea desbloqueado, e non debería intentar desbloquear un.

Planifique a desconexión antes de forzar a limpeza

Para unha desconexión planificada, remate as operacións de ficheiros e desmonte desde o propio fluxo de traballo do usuario que monta. Apunte ao punto de montaxe e non ao proceso, e confirme o resultado antes de informar de éxito.

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

Desmonte só a montaxe que creou este fluxo de traballo. Se está ocupada, é unha decisión da aplicación: unha separación forzada que existe para que un hook devolva éxito oculta a perda de datos en lugar de evitala.

A perda inesperada compórtase de forma distinta. SSHFS documenta que unha interrupción de rede pode bloquear unha operación do sistema de ficheiros, e a opción reconnect restaura o transporte sen restaurar os handles: un ficheiro aberto antes da reconexión pode fallar na seguinte escritura, e unha escritura interrompida non se conserva. Esa distinción importa sobre todo aos editores que manteñen un ficheiro aberto durante horas. Planifique un paso de reapertura en lugar de supor a recuperación.

Probe o comportamento con ficheiros dun só uso antes de confiar nel. Un directorio que reaparece despois de que o túnel volva non demostra que os handles anteriores ou o traballo non gardado sobrevivisen.