Criar um proxy SOCKS local com SSH

Com acesso SSH autorizado a um servidor, o OpenSSH pode criar um listener SOCKS no seu computador. A conexão SSH transporta o tráfego encaminhado, e o servidor remoto faz a conexão com o destino.

Um listener apenas no loopback

ssh -N -T -o ControlPath=none -o ForkAfterAuthentication=no -o ExitOnForwardFailure=yes -D 127.0.0.1:1080 [email protected]

Substitua a conta e o nome de host. O servidor SSH deve permitir encaminhamento; o administrador pode restringir encaminhamento e destinos independentemente do login na conta.

-D cria encaminhamento dinâmico, e o endereço loopback explícito limita o listener a esta máquina. -N omite um comando remoto; -T omite um pseudoterminal. ControlPath=none evita um mestre de compartilhamento existente, enquanto ForkAfterAuthentication=no mantém esta invocação em primeiro plano.

Mantenha o processo em execução enquanto usa o proxy. Se a porta 1080 estiver ocupada, escolha outra porta alta livre e atualize o cliente. ExitOnForwardFailure=yes faz o SSH sair se não conseguir criar o listener.

Usando o endpoint SOCKS

curl --proxy socks5h://127.0.0.1:1080 --noproxy '' --connect-timeout 5 --max-time 15 https://example.com/

Esta requisição delega o tratamento do nome de destino por SOCKS5. Outros aplicativos precisam de configuração SOCKS própria; um campo de proxy HTTP não consegue falar SOCKS com esse listener.

Para conferir qual processo possui a porta:

ss -ltnp 'sport = :1080'

O processo SSH pretendido deve possuir um listener loopback. Uma requisição por ele verifica se o servidor remoto também alcança o destino. Use um destino controlado quando precisar inspecionar a saída observada.

Vida útil da sessão

Ctrl-C fecha o processo SSH, o listener e as conexões encaminhadas. A queda da conexão SSH também deixa o proxy indisponível.

ExitOnForwardFailure verifica a configuração inicial. Ele não termina o SSH a cada falha posterior de conexão ao destino; diagnostique a sessão, a porta local e a requisição ao destino separadamente.