Mountain Duck SFTP: det andet login efter VPN

VPN'et forbinder, menulinjen viser en tunnel, og Mountain Duck beder stadig om et login. Derefter beder den om en kode. Intet er i stykker: to forskellige systemer godkender dig, og det andet har aldrig hørt om det første. VPN'ets MFA beviser noget over for gatewayen. SFTP-serveren beder om sit eget bevis, mod sin egen konto.

To prompter, to systemer

Gatewayen og filserveren er adskilte policy-domæner. De deler måske en mappe, eller de har måske intet til fælles ud over personen, der bruger dem. At sende en engangskode ved VPN'et opretter ikke en session på SFTP-værten, og SFTP-værten kan ikke se, om du overhovedet brugte en tunnel. Hvert system tror, det er det eneste, der spørger.

Behandl de tre som adskilte rækker i dine noter. Når en fejler, fortæller rækken dig, hvilken konsol du skal åbne, og det er det meste af arbejdet.

Brug SFTP-administratorens adresse

Et bogmærke skal have det værtsnavn og den port, filtjenesten faktisk lytter på, hvilket ikke nødvendigvis er VPN-serverens adresse. Spørg administratoren, der driver SFTP-tjenesten, og brug det samme værtsnavn, som andre klienter bruger.

Hold kontrollen af serveridentiteten intakt. Mountain Duck og Cyberduck viser værtsnøglen ved første forbindelse, og at sammenligne den med en værdi, administratoren leverer ad en anden kanal, er det trin, der forhindrer en forkert server i at modtage dine legitimationsoplysninger. At slå den kontrol fra for at få et bogmærke til at forbinde er en permanent beslutning forklædt som en bekvemmelighed. Det fjerner også det eneste bevis, du senere ville have for, at filen endte, hvor du havde tænkt dig.

Svar på den udfordring, serveren sender

Projektets SFTP-dokumentation beskriver challenge-response-understøttelse til engangskoder: en indledende loginprompt og derefter en anden prompt til koden, som serveren anmoder om. Forløbet hører til serverens konfiguration, og en klient kan ikke tilføje to-faktor-tvangsstyring på serversiden ved at gemme en anden værdi i sit adgangskodefelt.

Så bogmærket bør indeholde den almindelige kontolegitimation, og koden skal tastes, når prompten vises. Gemmer du en skiftende kode som den permanente adgangskode, får du et bogmærke, der virker én gang og derefter fejler på en måde, der ligner en forkert adgangskode. Lægger du koden i VPN'ets legitimationsfelt, fejler det anderledes: gatewayen afviser den, og tunnelen kommer aldrig op. To prompter, to steder, og at bytte dem ødelægger begge.

Automatisk montering kan ikke trykke på en knap

Hvis bogmærket genopretter forbindelsen i baggrunden, har en interaktiv udfordring ingen til at svare. Mountet prøver igen, serveren spørger igen, og loggen fyldes med forsøg, der ikke kan lykkes. Det er det ærlige resultat af en politik, der kræver en person.

Planlæg interaktionen: forbind tunnelen og bogmærket, mens du er til stede, og behandl senere automatiske genopkoblinger som bedste forsøg. Hvis arbejdsgangen virkelig kræver uovervåget adgang, skal serverejeren godkende en anden godkendelsesordning, hvilket er en ændring af politik og ikke en bogmærkeindstilling.

En montering er ikke en tilladelse

Et monteret drev beviser, at en session blev godkendt. Det beviser ikke, at kontoen må skrive overalt på den server. Kontrollér den tilsigtede mappe, prøv den handling, du faktisk har brug for, og bekræft resultatet fra serversiden, når svaret betyder noget. Finder-sidepanelet viser et drev; det siger intet om tilladelserne bag det.

Til en anden protokol bør du bruge den pågældende udbyders dokumenterede godkendelsesmetode i stedet for at kopiere denne sekvens. Et cloud-login og en SSH-udfordring kan se ens ud i sidepanelet og opføre sig helt forskelligt indeni.