Su contraseña SSH no es una contraseña SOCKS
Distinga el inicio de sesión SSH de la autenticación de cliente SOCKS en un oyente dinámico de OpenSSH.
Escribió una contraseña para iniciar ssh -D. Eso autenticó su conexión SSH. No creó una cuenta SOCKS protegida con contraseña para cada programa que pueda alcanzar el nuevo oyente.
El reenvío dinámico de OpenSSH ofrece un servicio SOCKS local sobre un transporte SSH autenticado. Su manejo de SOCKS5 elige el método sin autenticación; no es un servidor SOCKS general de usuario y contraseña.
Para uso personal, enlace localmente:
ssh -N -D 127.0.0.1:1080 [email protected]Las aplicaciones de ese equipo usan el puerto 1080 sin introducir su contraseña SSH como contraseña SOCKS. La documentación del reenvío dinámico describe el oyente, y el código de manejo SOCKS de OpenSSH aporta el detalle de autenticación.
Compartir cambia el problema
Enlazar a una dirección LAN hace que el puerto sea alcanzable más allá del uso local original. Los clientes cercanos no establecen sesiones SSH separadas solo porque su tráfico pase por la suya. Si la red permite el acceso, esos clientes pueden compartir la identidad externa de su puerta de enlace.
Un firewall puede restringir los clientes alcanzables, pero no añade un intercambio de inicio de sesión SOCKS. Para nombres de usuario SOCKS, cuotas o reglas por usuario separados, elija un servidor que admita esas funciones. Dante, por ejemplo, documenta la autenticación SOCKS por separado de las restricciones de dirección de cliente.
Esto también ayuda a diagnosticar problemas. Un cliente que insista en el método de usuario y contraseña SOCKS puede no negociar con este oyente como espera. Ajuste la aplicación o elija un servicio SOCKS autenticado adecuado; intentar repetidamente su contraseña SSH aborda el inicio de sesión equivocado.
La alcanzabilidad solo local sigue siendo un límite que entender, no una afirmación de que todos los procesos del equipo local pertenezcan al mismo usuario.