Crear un proxy SOCKS local con SSH
Usa reenvío dinámico de OpenSSH en 127.0.0.1, mantén el proceso activo durante la sesión y distingue un punto de escucha funcional de un destino accesible.
Con acceso SSH autorizado a un servidor, OpenSSH puede crear un punto de escucha SOCKS en tu equipo. La conexión SSH transporta el tráfico reenviado y el servidor remoto conecta con el destino.
Un punto de escucha solo en loopback
ssh -N -T -o ControlPath=none -o ForkAfterAuthentication=no -o ExitOnForwardFailure=yes -D 127.0.0.1:1080 [email protected]Sustituye la cuenta y el nombre de host. El servidor SSH debe permitir el reenvío; el administrador puede restringir reenvío y destinos independientemente del acceso a la cuenta.
-D crea reenvío dinámico, y la dirección loopback explícita limita el punto de escucha a este equipo. -N omite el comando remoto; -T omite el pseudoterminal. ControlPath=none evita un maestro de conexión compartida existente, mientras ForkAfterAuthentication=no mantiene esta invocación en primer plano.
Mantén el proceso activo mientras uses el proxy. Si el puerto 1080 está ocupado, elige otro puerto alto libre y actualiza el cliente. ExitOnForwardFailure=yes hace salir a SSH si no puede crear el punto de escucha.
Usar el endpoint SOCKS
curl --proxy socks5h://127.0.0.1:1080 --noproxy '' --connect-timeout 5 --max-time 15 https://example.com/Esta petición delega la gestión del nombre de destino mediante SOCKS5. Otras aplicaciones necesitan su propia configuración SOCKS; un campo de proxy HTTP no puede hablar SOCKS con este punto de escucha.
Para ver qué proceso posee el puerto:
ss -ltnp 'sport = :1080'El proceso SSH previsto debe poseer un punto de escucha loopback. Una petición a través de él comprueba si el servidor remoto también llega al destino. Usa un destino controlado cuando necesites inspeccionar la salida observada.
Duración de la sesión
Ctrl-C cierra el proceso SSH, el punto de escucha y las conexiones reenviadas. La caída de SSH también deja el proxy inaccesible.
ExitOnForwardFailure comprueba la preparación. No termina SSH cada vez que falla una conexión posterior al destino; diagnostica por separado la sesión, el puerto local y la petición al destino.