A VPN conéctase, a barra de menús mostra un túnel e Mountain Duck segue pedindo un inicio de sesión. Despois pide un código. Non hai nada roto: dous sistemas distintos o autentican e o segundo nunca oíu falar do primeiro. O MFA da VPN demostra algo á pasarela. O servidor SFTP pide a súa propia proba, contra a súa propia conta.

Dúas solicitudes, dous sistemas

A pasarela e o servidor de ficheiros son dominios de política separados. Poden compartir un directorio ou non ter nada en común agás a persoa que os usa. Pasar un código dun só uso na VPN non crea unha sesión no host SFTP, e o host SFTP non pode saber se usou un túnel. Cada sistema cre que é o único que pregunta.

LayerWhat it authenticatesWhere the account lives
VPNThe tunnel endpointGateway or identity provider
SFTPThe file sessionSSH server or its directory
Folder accessRead and write within the shareFilesystem permissions

Trate os tres como filas separadas nas súas notas. Cando un falla, a fila dille que consola abrir, e iso é a maior parte do traballo.

Use o enderezo do administrador de SFTP

Un marcador necesita o nome de host e o porto nos que o servizo de ficheiros realmente escoita, que non é necesariamente o enderezo do servidor VPN. Pregunte ao administrador que xestiona o servizo SFTP e use o mesmo nome de host que outros clientes.

Manteña intacta a comprobación de identidade do servidor. Mountain Duck e Cyberduck mostran a clave de host na primeira conexión, e comparala cun valor que o administrador fornece por outro canal é o paso que impide que un servidor equivocado reciba as súas credenciais. Desactivar esa comprobación para que un marcador se conecte é unha decisión permanente disfrazada de comodidade. Tamén elimina a única proba que tería despois de que o ficheiro foi onde quería.

Responda ao desafío que envía o servidor

A documentación SFTP do proxecto describe a compatibilidade con desafío-resposta para códigos dun só uso: unha solicitude inicial de inicio de sesión e logo unha segunda solicitude do código, como a pida o servidor. O fluxo pertence á configuración do servidor, e un cliente non pode engadir a esixencia de dobre factor do lado do servidor gardando outro valor no seu campo de contrasinal.

Así que o marcador debe gardar a credencial normal da conta, e o código debe escribirse cando apareza a solicitude. Gardar un código cambiante como contrasinal permanente produce un marcador que funciona unha vez e logo falla dun xeito que parece un contrasinal incorrecto. Poñer o código no campo de credenciais da VPN falla doutro xeito: a pasarela rexéitao e o túnel nunca se levanta. Dúas solicitudes, dous lugares, e intercambialos rompe ambos.

A montaxe automática non pode premer un botón

Se o marcador se reconecta en segundo plano, un desafío interactivo non ten a ninguén que o responda. A montaxe reintenta, o servidor volve preguntar e o rexistro énchese de intentos que non poden ter éxito. Ese é o resultado honesto dunha política que esixe unha persoa.

Planifique a interacción: conecte o túnel e o marcador mentres está presente, e logo trate as reconexións automáticas posteriores como mellor esforzo. Se o fluxo de traballo realmente necesita acceso sen supervisión, o propietario do servidor debe aprobar outra disposición de autenticación, que é un cambio de política e non un axuste do marcador.

Unha montaxe non é un permiso

Un volume montado demostra que unha sesión se autenticou. Non demostra que a conta poida escribir en todo ese servidor. Comprobe o cartafol previsto, probe a operación que realmente necesita e confirme o resultado desde o lado do servidor cando a resposta importe. A barra lateral do Finder mostra un volume; non di nada sobre os permisos que hai detrás.

Para outro protocolo, use o método de autenticación documentado dese provedor en lugar de copiar esta secuencia. Un inicio de sesión na nube e un desafío SSH poden parecer idénticos na barra lateral e comportarse de forma totalmente distinta por dentro.

Artigos relacionados