Twoje hasło SSH to nie hasło SOCKS
Odróżnij logowanie SSH od uwierzytelniania klienta SOCKS na dynamicznym nasłuchu OpenSSH.
Wpisałeś hasło, aby uruchomić ssh -D. Uwierzytelniło ono Twoje połączenie SSH. Nie utworzyło jednak chronionego hasłem konta SOCKS dla każdego programu, który może dotrzeć do nowego nasłuchu.
Przekazywanie dynamiczne OpenSSH dostarcza lokalną usługę SOCKS przez uwierzytelniony transport SSH. Jego obsługa SOCKS5 wybiera metodę bez uwierzytelniania; nie jest to ogólny serwer SOCKS z nazwą użytkownika i hasłem.
Do użytku osobistego powiąż lokalnie:
ssh -N -D 127.0.0.1:1080 [email protected]Aplikacje na tym komputerze używają portu 1080 bez wpisywania hasła SSH jako hasła SOCKS. Dokumentacja przekazywania dynamicznego opisuje nasłuch, a kod obsługi SOCKS w OpenSSH podaje szczegóły uwierzytelniania.
Udostępnianie zmienia problem
Powiązanie z adresem LAN czyni port osiągalnym poza pierwotnym użyciem lokalnym. Pobliskie klienty nie tworzą osobnych sesji SSH tylko dlatego, że ich ruch przechodzi przez Twój. Jeśli sieć pozwala na dostęp, klienty te mogą dzielić zewnętrzną tożsamość Twojej bramy.
Zapora może ograniczyć osiągalne klienty, ale nie dodaje wymiany logowania SOCKS. Dla osobnych nazw użytkowników SOCKS, limitów lub reguł na użytkownika wybierz serwer obsługujący te funkcje. Dante na przykład dokumentuje uwierzytelnianie SOCKS oddzielnie od ograniczeń adresów klientów.
Pomaga to również w rozwiązywaniu problemów. Klient nalegający na metodę nazwy użytkownika i hasła SOCKS może nie negocjować z tym nasłuchem zgodnie z oczekiwaniami. Dostosuj aplikację lub wybierz odpowiednią uwierzytelnioną usługę SOCKS; wielokrotne próby hasła SSH dotyczą niewłaściwego logowania.
Osiągalność wyłącznie lokalna pozostaje granicą do zrozumienia, a nie twierdzeniem, że każdy proces na komputerze lokalnym należy do tego samego użytkownika.