Mountain Duck SFTP: drugie logowanie po VPN
Brama i serwer plików uwierzytelniają różne rzeczy. Użyj nazwy hosta od administratora SFTP, odpowiedz na jego monit i zachowaj sprawdzanie klucza hosta.
VPN się łączy, pasek menu pokazuje tunel, a Mountain Duck nadal prosi o zalogowanie. Potem prosi o kod. Nic nie jest zepsute: dwa różne systemy uwierzytelniają użytkownika, a drugi nigdy nie słyszał o pierwszym. MFA w VPN dowodzi czegoś bramie. Serwer SFTP żąda własnego dowodu, wobec własnego konta.
Dwa monity, dwa systemy
Brama i serwer plików to odrębne domeny polityki. Mogą dzielić katalog albo nie mieć nic wspólnego poza osobą, która ich używa. Przekazanie jednorazowego kodu na VPN nie tworzy sesji na hoście SFTP, a host SFTP nie może wiedzieć, czy w ogóle korzystano z tunelu. Każdy system sądzi, że tylko on pyta.
| 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 |
Traktuj te trzy jako osobne wiersze w notatkach. Gdy jeden zawiedzie, wiersz mówi, którą konsolę otworzyć, i to jest większość pracy.
Użyj adresu administratora SFTP
Zakładka potrzebuje nazwy hosta i portu, na których usługa plików faktycznie nasłuchuje, co nie musi być adresem serwera VPN. Zapytaj administratora, który prowadzi usługę SFTP, i użyj tej samej nazwy hosta co inni klienci.
Zachowaj nienaruszone sprawdzanie tożsamości serwera. Mountain Duck i Cyberduck pokazują klucz hosta przy pierwszym połączeniu, a porównanie go z wartością, którą administrator podaje innym kanałem, to krok, który nie pozwala niewłaściwemu serwerowi odebrać danych logowania. Wyłączenie tego sprawdzania, żeby zakładka się połączyła, to trwała decyzja przebrana za wygodę. Usuwa też jedyny dowód, jaki później miałbyś, że plik trafił tam, gdzie chciałeś.
Odpowiedz na wyzwanie wysłane przez serwer
Dokumentacja SFTP projektu opisuje obsługę wyzwania i odpowiedzi dla kodów jednorazowych: początkowy monit logowania, potem drugi monit o kod, zgodnie z żądaniem serwera. Ten przepływ należy do konfiguracji serwera, a klient nie może dodać wymuszania dwuskładnikowego po stronie serwera, zapisując inną wartość w polu hasła.
Zakładka powinna więc zawierać zwykłe dane logowania konta, a kod wpisuje się, gdy pojawi się monit. Zapisanie zmiennego kodu jako stałego hasła daje zakładkę, która działa raz, a potem zawodzi w sposób wyglądający jak błędne hasło. Wstawienie kodu w pole danych logowania VPN zawodzi inaczej: brama go odrzuca i tunel nigdy nie wstaje. Dwa monity, dwa miejsca, a zamiana ich psuje oba.
Automatyczne montowanie nie może nacisnąć przycisku
Jeśli zakładka łączy się ponownie w tle, interaktywne wyzwanie nie ma kto odpowiedzieć. Montowanie ponawia próbę, serwer pyta ponownie, a dziennik wypełnia się próbami, które nie mogą się udać. To uczciwy wynik polityki, która wymaga człowieka.
Zaplanuj interakcję: połącz tunel i zakładkę, gdy jesteś obecny, a późniejsze automatyczne ponowne połączenia traktuj jako najlepszy wysiłek. Jeśli przepływ pracy naprawdę wymaga dostępu bez nadzoru, właściciel serwera musi zatwierdzić inny układ uwierzytelniania, co jest zmianą polityki, a nie ustawieniem zakładki.
Zamontowanie to nie uprawnienie
Zamontowany wolumen dowodzi, że sesja została uwierzytelniona. Nie dowodzi, że konto może pisać wszędzie na tym serwerze. Sprawdź zamierzony folder, wypróbuj operację, której naprawdę potrzebujesz, i potwierdź wynik po stronie serwera, gdy odpowiedź ma znaczenie. Pasek boczny Findera pokazuje wolumen; nie mówi nic o uprawnieniach za nim.
Dla innego protokołu użyj udokumentowanej metody uwierzytelniania tego dostawcy, zamiast kopiować tę sekwencję. Logowanie w chmurze i wyzwanie SSH mogą w pasku bocznym wyglądać identycznie i zachowywać się zupełnie inaczej pod spodem.