SSH-passordet ditt er ikke et SOCKS-passord

Du skrev inn et passord for å starte ssh -D. Det autentiserte SSH-tilkoblingen din. Det opprettet ikke en passordbeskyttet SOCKS-konto for hvert program som kan nå den nye lytteren.

OpenSSHs dynamiske videresending leverer en lokal SOCKS-tjeneste over en autentisert SSH-transport. SOCKS5-håndteringen velger metoden uten autentisering; den er ikke en generell SOCKS-tjener med brukernavn og passord.

For personlig bruk, bind lokalt:

ssh -N -D 127.0.0.1:1080 [email protected]

Programmer på den datamaskinen bruker port 1080 uten å taste inn SSH-passordet ditt som SOCKS-passord. Dokumentasjonen for dynamisk videresending beskriver lytteren, og OpenSSHs kildekode for SOCKS-håndtering gir autentiseringsdetaljen.

Deling endrer problemet

Binding til en LAN-adresse gjør porten tilgjengelig utover den opprinnelige lokale bruken. Nærliggende klienter oppretter ikke separate SSH-økter bare fordi trafikken deres går gjennom din. Hvis nettverket tillater tilgang, kan disse klientene dele den utgående identiteten til gatewayen din.

En brannmur kan begrense tilgjengelige klienter, men legger ikke til en SOCKS-innloggingsutveksling. For separate SOCKS-brukernavn, kvoter eller regler per bruker, velg en tjener som støtter disse funksjonene. Dante dokumenterer for eksempel SOCKS-autentisering atskilt fra klientadressebegrensninger.

Dette hjelper også med feilsøking. En klient som insisterer på SOCKS-brukernavn/passord-metoden, forhandler kanskje ikke med denne lytteren som forventet. Juster programmet eller velg en passende autentisert SOCKS-tjeneste; gjentatte forsøk med SSH-passordet ditt adresserer feil innlogging.

Kun lokal tilgjengelighet er fortsatt en grense å forstå, ikke en påstand om at hver prosess på den lokale datamaskinen tilhører samme bruker.