Din SSH-adgangskode er ikke en SOCKS-adgangskode
Skeln mellem SSH-login og SOCKS-klientgodkendelse på en dynamisk OpenSSH-lytter.
Du skrev en adgangskode for at starte ssh -D. Den godkendte din SSH-forbindelse. Den oprettede ikke en adgangskodebeskyttet SOCKS-konto til hvert program, der kan nå den nye lytter.
OpenSSH's dynamiske videresendelse leverer en lokal SOCKS-tjeneste over en godkendt SSH-transport. Dens SOCKS5-håndtering vælger metoden uden godkendelse; den er ikke en generel SOCKS-server med brugernavn og adgangskode.
Til personligt brug, bind lokalt:
ssh -N -D 127.0.0.1:1080 [email protected]Programmer på den computer bruger port 1080 uden at indtaste din SSH-adgangskode som SOCKS-adgangskode. Dokumentationen for dynamisk videresendelse beskriver lytteren, og OpenSSH's kildekode til SOCKS-håndtering giver godkendelsesdetaljen.
Deling ændrer problemet
Binding til en LAN-adresse gør porten nåbar ud over den oprindelige lokale brug. Nærliggende klienter opretter ikke separate SSH-sessioner, blot fordi deres trafik går gennem din. Hvis netværket tillader adgang, kan disse klienter dele din gateways udadgående identitet.
En firewall kan begrænse nåbare klienter, men tilføjer ikke en SOCKS-loginudveksling. Til separate SOCKS-brugernavne, kvoter eller regler pr. bruger skal du vælge en server, der understøtter disse funktioner. Dante dokumenterer for eksempel SOCKS-godkendelse separat fra klientadressebegrænsninger.
Det hjælper også med fejlfinding. En klient, der insisterer på SOCKS-brugernavn/-adgangskode-metoden, forhandler måske ikke med denne lytter, som du forventer. Juster programmet, eller vælg en passende godkendt SOCKS-tjeneste; gentagne forsøg med din SSH-adgangskode adresserer det forkerte login.
Kun lokal nåbarhed er stadig en grænse at forstå, ikke en påstand om, at enhver proces på den lokale computer tilhører den samme bruger.