Uw SSH-wachtwoord is geen SOCKS-wachtwoord

U typte een wachtwoord om ssh -D te starten. Dat verifieerde uw SSH-verbinding. Het maakte geen met een wachtwoord beveiligd SOCKS-account voor elk programma dat de nieuwe listener kan bereiken.

De dynamische doorsturing van OpenSSH biedt een lokale SOCKS-dienst via een geverifieerd SSH-transport. De SOCKS5-afhandeling kiest de methode zonder verificatie; het is geen algemene SOCKS-server met gebruikersnaam en wachtwoord.

Voor persoonlijk gebruik, bind lokaal:

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

Programma's op die computer gebruiken poort 1080 zonder uw SSH-wachtwoord als SOCKS-wachtwoord in te voeren. De documentatie over dynamische doorsturing beschrijft de listener, en de SOCKS-broncode van OpenSSH levert het verificatiedetail.

Delen verandert het probleem

Binden aan een LAN-adres maakt de poort bereikbaar buiten het oorspronkelijke lokale gebruik. Nabije clients openen geen aparte SSH-sessies alleen omdat hun verkeer via de uwe loopt. Als het netwerk toegang toestaat, kunnen die clients de naar buiten gerichte identiteit van uw gateway delen.

Een firewall kan bereikbare clients beperken, maar voegt geen SOCKS-loginuitwisseling toe. Voor afzonderlijke SOCKS-gebruikersnamen, quota of regels per gebruiker kiest u een server die die functies ondersteunt. Dante documenteert bijvoorbeeld SOCKS-verificatie apart van clientadresbeperkingen.

Dit helpt ook bij het oplossen van problemen. Een client die op de SOCKS-methode met gebruikersnaam en wachtwoord staat, onderhandelt mogelijk niet zoals verwacht met deze listener. Pas de toepassing aan of kies een geschikte geverifieerde SOCKS-dienst; uw SSH-wachtwoord herhaaldelijk proberen richt zich op de verkeerde login.

Alleen lokaal bereik blijft een grens om te begrijpen, geen bewering dat elk proces op de lokale computer bij dezelfde gebruiker hoort.