SSH-passordet ditt er ikkje eit SOCKS-passord

Du skreiv inn eit passord for å starte ssh -D. Det autentiserte SSH-tilkoplinga di. Det oppretta ikkje ein passordverna SOCKS-konto for kvart program som kan nå den nye lyttaren.

OpenSSH si dynamiske videresending leverer ei lokal SOCKS-teneste over ein autentisert SSH-transport. SOCKS5-handteringa vel metoden utan autentisering; ho er ikkje ein generell SOCKS-tenar med brukarnamn og passord.

For personleg bruk, bind lokalt:

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

Program på den datamaskinen brukar port 1080 utan å skrive inn SSH-passordet ditt som SOCKS-passord. Dokumentasjonen for dynamisk videresending skildrar lyttaren, og OpenSSH sin kildekode for SOCKS-handtering gjev autentiseringsdetaljen.

Deling endrar problemet

Binding til ein LAN-adresse gjer porten tilgjengeleg utover den opphavlege lokale bruken. Nærliggande klientar opprettar ikkje separate SSH-økter berre fordi trafikken deira går gjennom din. Viss nettverket tillét tilgang, kan desse klientane dele den utåtgåande identiteten til gatewayen din.

Ein brannmur kan avgrense tilgjengelege klientar, men legg ikkje til ei SOCKS-innloggingsutveksling. For separate SOCKS-brukarnamn, kvotar eller reglar per brukar, vel ein tenar som støttar desse funksjonane. Dante dokumenterer til dømes SOCKS-autentisering skilt frå klientadresseavgrensingar.

Dette hjelper òg med feilsøking. Ein klient som insisterer på SOCKS-brukarnamn/passord-metoden, forhandlar kanskje ikkje med denne lyttaren som forventa. Juster programmet eller vel ei høveleg autentisert SOCKS-teneste; gjentekne forsøk med SSH-passordet ditt adresserer feil innlogging.

Berre lokal tilgjenge er framleis ei grense å forstå, ikkje påstand om at kvar prosess på den lokale datamaskinen høyrer til same brukar.