Mountain Duck SFTP: il secondo accesso dopo la VPN

La VPN si connette, la barra dei menu mostra un tunnel e Mountain Duck chiede comunque un accesso. Poi chiede un codice. Niente è rotto: due sistemi diversi vi autenticano e il secondo non ha mai sentito parlare del primo. L’MFA della VPN dimostra qualcosa al gateway. Il server SFTP chiede la propria prova, contro il proprio account.

Due prompt, due sistemi

Il gateway e il file server sono domini di policy separati. Possono condividere una cartella o non avere nulla in comune tranne la persona che li usa. Passare un codice monouso sulla VPN non crea una sessione sull’host SFTP, e l’host SFTP non può sapere se avete usato un tunnel. Ogni sistema crede di essere l’unico a chiedere.

Trattate i tre come righe separate nelle vostre note. Quando uno fallisce, la riga vi dice quale console aprire, ed è la maggior parte del lavoro.

Usate l’indirizzo dell’amministratore SFTP

Un segnalibro ha bisogno del nome host e della porta su cui il servizio file ascolta davvero, che non è necessariamente l’indirizzo del server VPN. Chiedete all’amministratore che gestisce il servizio SFTP e usate lo stesso nome host che usano gli altri client.

Lasciate intatto il controllo dell’identità del server. Mountain Duck e Cyberduck mostrano la chiave host alla prima connessione, e confrontarla con un valore che l’amministratore fornisce su un altro canale è il passo che impedisce a un server sbagliato di ricevere le vostre credenziali. Disattivare quel controllo perché un segnalibro si connetta è una decisione permanente travestita da comodità. Elimina anche l’unica prova che avreste poi che il file è andato dove volevate.

Rispondete alla sfida che invia il server

La documentazione SFTP del progetto descrive il supporto challenge-response per i codici monouso: un prompt di accesso iniziale, poi un secondo prompt per il codice, come lo richiede il server. Il flusso appartiene alla configurazione del server, e un client non può aggiungere l’applicazione del doppio fattore lato server salvando un altro valore nel proprio campo password.

Quindi il segnalibro deve contenere la credenziale ordinaria dell’account, e il codice va digitato quando appare il prompt. Salvare un codice variabile come password permanente produce un segnalibro che funziona una volta, poi fallisce in un modo che sembra una password sbagliata. Mettere il codice nel campo credenziali della VPN fallisce diversamente: il gateway lo rifiuta e il tunnel non si alza mai. Due prompt, due posti, e scambiarli rompe entrambi.

Il montaggio automatico non può premere un pulsante

Se il segnalibro si riconnette in background, una sfida interattiva non ha nessuno che risponda. Il mount riprova, il server richiede di nuovo e il registro si riempie di tentativi che non possono riuscire. È il risultato onesto di una policy che richiede una persona.

Pianificate l’interazione: collegate il tunnel e il segnalibro mentre siete presenti, poi trattate le riconnessioni automatiche successive come miglior tentativo. Se il flusso di lavoro richiede davvero accesso senza sorveglianza, il proprietario del server deve approvare un’altra disposizione di autenticazione, che è un cambio di policy e non un’impostazione del segnalibro.

Un montaggio non è un’autorizzazione

Un volume montato prova che una sessione è stata autenticata. Non prova che l’account possa scrivere ovunque su quel server. Controllate la cartella prevista, provate l’operazione che vi serve davvero e confermate il risultato dal lato server quando la risposta conta. La barra laterale del Finder mostra un volume; non dice nulla sui permessi che ci sono dietro.

Per un altro protocollo, usate il metodo di autenticazione documentato di quel fornitore invece di copiare questa sequenza. Un accesso cloud e una sfida SSH possono sembrare identici nella barra laterale e comportarsi in modo del tutto diverso sotto.