Parola dvs. SSH nu este o parolă SOCKS
Distingeți autentificarea SSH de autentificarea clientului SOCKS pe un ascultător dinamic OpenSSH.
Ați tastat o parolă pentru a porni ssh -D. Aceasta v-a autentificat conexiunea SSH. Nu a creat un cont SOCKS protejat prin parolă pentru fiecare program care poate ajunge la noul ascultător.
Redirecționarea dinamică a OpenSSH oferă un serviciu SOCKS local printr-un transport SSH autentificat. Gestionarea SOCKS5 alege metoda fără autentificare; nu este un server SOCKS general cu nume de utilizator și parolă.
Pentru uz personal, legați local:
ssh -N -D 127.0.0.1:1080 [email protected]Aplicațiile de pe acel calculator folosesc portul 1080 fără a introduce parola SSH ca parolă SOCKS. Documentația redirecționării dinamice descrie ascultătorul, iar codul de gestionare SOCKS al OpenSSH oferă detaliul autentificării.
Partajarea schimbă problema
Legarea la o adresă LAN face portul accesibil dincolo de utilizarea locală inițială. Clienții din apropiere nu stabilesc sesiuni SSH separate doar pentru că traficul lor trece prin al dvs. Dacă rețeaua permite accesul, acei clienți pot partaja identitatea externă a gateway-ului dvs.
Un firewall poate restricționa clienții accesibili, dar nu adaugă un schimb de autentificare SOCKS. Pentru nume de utilizator SOCKS, cote sau reguli pe utilizator separate, alegeți un server care acceptă aceste funcții. Dante, de exemplu, documentează autentificarea SOCKS separat de restricțiile de adresă a clientului.
Acest lucru ajută și la depanare. Un client care insistă pe metoda nume de utilizator/parolă SOCKS poate să nu negocieze cu acest ascultător așa cum vă așteptați. Ajustați aplicația sau alegeți un serviciu SOCKS autentificat potrivit; încercarea repetată a parolei SSH abordează autentificarea greșită.
Accesibilitatea doar locală rămâne o limită de înțeles, nu o afirmație că fiecare proces de pe calculatorul local aparține aceluiași utilizator.