O seu contrasinal SSH non é un contrasinal SOCKS

Escribiu un contrasinal para iniciar ssh -D. Iso autenticou a súa conexión SSH. Non creou unha conta SOCKS protexida con contrasinal para cada programa que poida acadar o novo oínte.

O reenvío dinámico de OpenSSH ofrece un servizo SOCKS local sobre un transporte SSH autenticado. O seu manexo de SOCKS5 escolle o método sen autenticación; non é un servidor SOCKS xeral de usuario e contrasinal.

Para uso persoal, vincule localmente:

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

As aplicacións dese equipo usan o porto 1080 sen introducir o seu contrasinal SSH como contrasinal SOCKS. A documentación do reenvío dinámico describe o oínte, e o código de manexo SOCKS de OpenSSH achega o detalle da autenticación.

Compartir cambia o problema

Vincular a un enderezo LAN fai que o porto sexa alcanzable máis alá do uso local orixinal. Os clientes próximos non establecen sesións SSH separadas só porque o seu tráfico pase polo seu. Se a rede permite o acceso, eses clientes poden compartir a identidade externa da súa pasarela.

Unha devasa pode restrinxir os clientes alcanzables, pero non engade un intercambio de inicio de sesión SOCKS. Para nomes de usuario SOCKS, cotas ou regras por usuario separados, escolla un servidor que admita esas funcións. Dante, por exemplo, documenta a autenticación SOCKS por separado das restricións de enderezo de cliente.

Isto tamén axuda a diagnosticar problemas. Un cliente que insista no método de usuario e contrasinal SOCKS pode non negociar con este oínte como espera. Axuste a aplicación ou escolla un servizo SOCKS autenticado axeitado; tentar repetidamente o seu contrasinal SSH aborda o inicio de sesión incorrecto.

A alcanzabilidade só local segue sendo un límite que comprender, non unha afirmación de que todos os procesos do equipo local pertenzan ao mesmo usuario.