Mountain Duck SFTP: o segundo início de sessão depois da VPN

A VPN liga-se, a barra de menus mostra um túnel e o Mountain Duck continua a pedir um início de sessão. Depois pede um código. Nada está avariado: dois sistemas diferentes autenticam-no e o segundo nunca ouviu falar do primeiro. O MFA da VPN prova algo ao gateway. O servidor SFTP pede a sua própria prova, contra a sua própria conta.

Dois pedidos, dois sistemas

O gateway e o servidor de ficheiros são domínios de política separados. Podem partilhar um diretório ou não ter nada em comum além da pessoa que os usa. Passar um código de utilização única na VPN não cria uma sessão no anfitrião SFTP, e o anfitrião SFTP não consegue saber se usou um túnel. Cada sistema acredita ser o único a perguntar.

Trate os três como linhas separadas nas suas notas. Quando um falha, a linha diz que consola abrir, e isso é a maior parte do trabalho.

Use o endereço do administrador do SFTP

Um marcador precisa do nome de anfitrião e da porta em que o serviço de ficheiros realmente escuta, que não é necessariamente o endereço do servidor VPN. Pergunte ao administrador que gere o serviço SFTP e use o mesmo nome de anfitrião que os outros clientes.

Mantenha intacta a verificação da identidade do servidor. O Mountain Duck e o Cyberduck mostram a chave do anfitrião na primeira ligação, e compará-la com um valor que o administrador fornece por outro canal é o passo que impede um servidor errado de receber as suas credenciais. Desativar essa verificação para que um marcador ligue é uma decisão permanente disfarçada de comodidade. Também elimina a única prova que teria depois de que o ficheiro foi onde queria.

Responda ao desafio que o servidor envia

A documentação SFTP do projeto descreve o suporte de desafio-resposta para códigos de utilização única: um pedido inicial de início de sessão e depois um segundo pedido do código, como o servidor o exige. O fluxo pertence à configuração do servidor, e um cliente não pode acrescentar a exigência de dois fatores do lado do servidor guardando outro valor no seu campo de palavra-passe.

Por isso o marcador deve guardar a credencial normal da conta, e o código deve ser escrito quando o pedido aparecer. Guardar um código variável como palavra-passe permanente produz um marcador que funciona uma vez e depois falha de uma forma que parece uma palavra-passe errada. Pôr o código no campo de credenciais da VPN falha de outra maneira: o gateway rejeita-o e o túnel nunca sobe. Dois pedidos, dois lugares, e trocá-los parte ambos.

A montagem automática não consegue premir um botão

Se o marcador se voltar a ligar em segundo plano, um desafio interativo não tem quem lhe responda. A montagem tenta novamente, o servidor volta a perguntar e o registo enche-se de tentativas que não podem ter sucesso. Esse é o resultado honesto de uma política que exige uma pessoa.

Planeie a interação: ligue o túnel e o marcador enquanto está presente, e depois trate as reconexões automáticas posteriores como melhor esforço. Se o fluxo de trabalho precisar realmente de acesso sem supervisão, o proprietário do servidor tem de aprovar outra disposição de autenticação, o que é uma mudança de política e não um ajuste do marcador.

Uma montagem não é uma permissão

Um volume montado prova que uma sessão foi autenticada. Não prova que a conta possa escrever em todo esse servidor. Verifique a pasta prevista, experimente a operação de que realmente precisa e confirme o resultado do lado do servidor quando a resposta importa. A barra lateral do Finder mostra um volume; não diz nada sobre as permissões por trás.

Para outro protocolo, use o método de autenticação documentado desse fornecedor em vez de copiar esta sequência. Um início de sessão na nuvem e um desafio SSH podem parecer idênticos na barra lateral e comportar-se de forma completamente diferente por dentro.