Ditt SSH-lösenord är inte ett SOCKS-lösenord

Du skrev ett lösenord för att starta ssh -D. Det autentiserade din SSH-anslutning. Det skapade inte ett lösenordsskyddat SOCKS-konto för varje program som kan nå den nya lyssnaren.

OpenSSH:s dynamiska vidarebefordran tillhandahåller en lokal SOCKS-tjänst över en autentiserad SSH-transport. Dess SOCKS5-hantering väljer metoden utan autentisering; det är inte en allmän SOCKS-server med användarnamn och lösenord.

För personligt bruk, bind lokalt:

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

Program på den datorn använder port 1080 utan att ange ditt SSH-lösenord som SOCKS-lösenord. Dokumentationen för dynamisk vidarebefordran beskriver lyssnaren, och OpenSSH:s källkod för SOCKS-hantering ger autentiseringsdetaljen.

Delning ändrar problemet

Bindning till en LAN-adress gör porten nåbar utanför den ursprungliga lokala användningen. Närliggande klienter upprättar inte separata SSH-sessioner bara för att deras trafik går genom din. Om nätverket tillåter åtkomst kan dessa klienter dela din gateways utåtriktade identitet.

En brandvägg kan begränsa nåbara klienter men lägger inte till ett SOCKS-inloggningsutbyte. För separata SOCKS-användarnamn, kvoter eller regler per användare, välj en server som stöder dessa funktioner. Dante dokumenterar till exempel SOCKS-autentisering separat från klientadressbegränsningar.

Detta hjälper även vid felsökning. En klient som insisterar på SOCKS-användarnamn/lösenordsmetoden förhandlar kanske inte med denna lyssnare som du förväntar dig. Justera programmet eller välj en lämplig autentiserad SOCKS-tjänst; upprepade försök med ditt SSH-lösenord adresserar fel inloggning.

Endast lokal nåbarhet är fortfarande en gräns att förstå, inte ett påstående att varje process på den lokala datorn tillhör samma användare.