La vostra contrasenya SSH no és una contrasenya SOCKS
Distingiu l'inici de sessió SSH de l'autenticació de client SOCKS en un oient dinàmic d'OpenSSH.
Heu escrit una contrasenya per iniciar ssh -D. Va autenticar la vostra connexió SSH. No va crear un compte SOCKS protegit amb contrasenya per a cada programa que pugui arribar a l'oient nou.
El reenviament dinàmic d'OpenSSH ofereix un servei SOCKS local sobre un transport SSH autenticat. El seu tractament de SOCKS5 tria el mètode sense autenticació; no és un servidor SOCKS general d'usuari i contrasenya.
Per a ús personal, enllaceu localment:
ssh -N -D 127.0.0.1:1080 [email protected]Les aplicacions d'aquell ordinador utilitzen el port 1080 sense introduir la vostra contrasenya SSH com a contrasenya SOCKS. La documentació del reenviament dinàmic descriu l'oient, i el codi de tractament SOCKS d'OpenSSH forneix el detall de l'autenticació.
Compartir canvia el problema
Enllaçar amb una adreça LAN fa que el port sigui abastable més enllà de l'ús local original. Els clients propers no estableixen sessions SSH separades només perquè el seu trànsit passi pel vostre. Si la xarxa permet l'accés, aquests clients poden compartir la identitat externa de la vostra passarel·la.
Un tallafoc pot restringir els clients abastables, però no afegeix cap intercanvi d'inici de sessió SOCKS. Per a noms d'usuari SOCKS, quotes o regles per usuari separats, trieu un servidor que admeti aquestes funcions. Dante, per exemple, documenta l'autenticació SOCKS per separat de les restriccions d'adreça de client.
Això també ajuda a diagnosticar problemes. Un client que insisteixi en el mètode d'usuari i contrasenya SOCKS pot no negociar amb aquest oient com espereu. Ajusteu l'aplicació o trieu un servei SOCKS autenticat adequat; provar repetidament la vostra contrasenya SSH aborda l'inici de sessió equivocat.
L'abast només local continua sent una frontera a entendre, no una afirmació que tots els processos de l'ordinador local pertanyin al mateix usuari.