Mountain Duck SFTP: den andre påloggingen etter VPN
Gatewayen og filserveren autentiserer forskjellige ting. Bruk vertsnavnet til SFTP-administratoren, svar på forespørselen og behold vertsnøkkelkontrollen.
VPN kobler til, menylinjen viser en tunnel, og Mountain Duck ber likevel om pålogging. Så ber den om en kode. Ingenting er ødelagt: to forskjellige systemer autentiserer deg, og det andre har aldri hørt om det første. MFA-en til VPN beviser noe overfor gatewayen. SFTP-serveren krever sitt eget bevis, mot sin egen konto.
To forespørsler, to systemer
Gatewayen og filserveren er separate policydomener. De deler kanskje en mappe, eller de har kanskje ingenting felles utover personen som bruker dem. Å sende en engangskode på VPN oppretter ikke en økt på SFTP-verten, og SFTP-verten kan ikke vite om du brukte en tunnel i det hele tatt. Hvert system tror det er det eneste som spør.
| Layer | What it authenticates | Where the account lives |
|---|---|---|
| VPN | The tunnel endpoint | Gateway or identity provider |
| SFTP | The file session | SSH server or its directory |
| Folder access | Read and write within the share | Filesystem permissions |
Behandle de tre som separate rader i notatene dine. Når en feiler, forteller raden deg hvilken konsoll du skal åpne, og det er mesteparten av arbeidet.
Bruk adressen til SFTP-administratoren
Et bokmerke trenger vertsnavnet og porten filtjenesten faktisk lytter på, som ikke nødvendigvis er adressen til VPN-serveren. Spør administratoren som driver SFTP-tjenesten, og bruk samme vertsnavn som andre klienter.
Hold kontrollen av serveridentitet intakt. Mountain Duck og Cyberduck viser vertsnøkkelen ved første tilkobling, og å sammenligne den med en verdi administratoren oppgir gjennom en annen kanal er trinnet som hindrer en feil server i å motta legitimasjonen din. Å slå av den kontrollen for at et bokmerke skal koble til er en permanent avgjørelse forkledd som bekvemmelighet. Den fjerner også det eneste beviset du senere ville hatt for at filen havnet der du mente.
Svar på utfordringen serveren sender
Prosjektets SFTP-dokumentasjon beskriver støtte for utfordring-respons for engangskoder: en innledende påloggingsforespørsel, deretter en andre forespørsel for koden, slik serveren ber om. Flyten tilhører serverens konfigurasjon, og en klient kan ikke legge til tofaktorstvang på serversiden ved å lagre en annen verdi i passordfeltet.
Så bokmerket bør inneholde den vanlige kontolegitimasjonen, og koden bør skrives når forespørselen dukker opp. Å lagre en skiftende kode som permanent passord gir et bokmerke som virker én gang, og deretter feiler på en måte som ser ut som et feil passord. Å legge koden i legitimasjonsfeltet til VPN feiler annerledes: gatewayen avviser den, og tunnelen kommer aldri opp. To forespørsler, to steder, og å bytte dem ødelegger begge.
Automatisk montering kan ikke trykke på en knapp
Hvis bokmerket kobler til på nytt i bakgrunnen, har en interaktiv utfordring ingen til å svare. Moneringen prøver igjen, serveren spør igjen, og loggen fylles med forsøk som ikke kan lykkes. Det er det ærlige resultatet av en policy som krever en person.
Planlegg samhandlingen: koble til tunnelen og bokmerket mens du er til stede, og behandle senere automatiske gjenoppkoblinger som beste innsats. Hvis arbeidsflyten virkelig trenger uovervåket tilgang, må servereieren godkjenne en annen autentiseringsordning, noe som er en policyendring og ikke en bokmerkeinnstilling.
Montering er ikke tillatelse
Et montert volum beviser at en økt ble autentisert. Det beviser ikke at kontoen kan skrive overalt på den serveren. Sjekk den tiltenkte mappen, prøv operasjonen du faktisk trenger, og bekreft resultatet fra serversiden når svaret betyr noe. Finder-sidepanelet viser et volum; det sier ingenting om tillatelsene bak.
For en annen protokoll, bruk den dokumenterte autentiseringsmetoden til den leverandøren i stedet for å kopiere denne sekvensen. En skyinnlogging og en SSH-utfordring kan se identiske ut i sidepanelet og oppføre seg helt annerledes under.