Jou SSH-wagwoord is nie 'n SOCKS-wagwoord nie

Jy het 'n wagwoord getik om ssh -D te begin. Dit het jou SSH-verbinding verifieer. Dit het nie 'n wagwoordbeskermde SOCKS-rekening geskep vir elke program wat die nuwe luisteraar kan bereik nie.

OpenSSH se dinamiese aanstuur bied 'n plaaslike SOCKS-diens oor 'n geverifieerde SSH-vervoer. Sy SOCKS5-hantering kies die metode sonder verifikasie; dit is nie 'n algemene SOCKS-gebruikersnaam/wagwoord-bediener nie.

Vir persoonlike gebruik, bind plaaslik:

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

Toepassings op daardie rekenaar gebruik poort 1080 sonder om jou SSH-wagwoord as 'n SOCKS-wagwoord in te voer. Die dokumentasie oor dinamiese aanstuur beskryf die luisteraar, en OpenSSH se SOCKS-bronkode verskaf die verifikasiedetail.

Deling verander die probleem

Om aan 'n LAN-adres te bind, maak die poort bereikbaar buite die oorspronklike plaaslike gebruik. Nabygeleë kliënte stig nie aparte SSH-sessies net omdat hul verkeer deur joune loop nie. As die netwerk toegang toelaat, kan daardie kliënte jou gateway se uitwaartse identiteit deel.

'n Firewall kan bereikbare kliënte beperk, maar voeg nie 'n SOCKS-aanmeldingsuitruiling by nie. Vir aparte SOCKS-gebruikersname, kwotas of reëls per gebruiker, kies 'n bediener wat daardie kenmerke ondersteun. Dante dokumenteer byvoorbeeld SOCKS-verifikasie apart van kliëntadresbeperkings.

Dit help ook met probleemoplossing. 'n Kliënt wat op die SOCKS-gebruikersnaam/wagwoord-metode aandring, onderhandel dalk nie soos verwag met hierdie luisteraar nie. Pas die toepassing aan of kies 'n geskikte geverifieerde SOCKS-diens; om jou SSH-wagwoord herhaaldelik te probeer, spreek die verkeerde aanmelding aan.

Slegs plaaslike bereikbaarheid is steeds 'n grens om te verstaan, nie 'n bewering dat elke proses op die plaaslike rekenaar aan dieselfde gebruiker behoort nie.