Por que o wget não funciona via túnel ssh? O que o proxy impede que o ssh-client faça?

Question

Para testar coisas, estou tentando estabelecer um túnel ssh local do meu laptop para um site via ssh-server , e baixar uma página do site (ou visualizá-lo em um navegador).

O túnel é feito assim:

$ ssh -L 9999:www.gnu.org:80 ssh-server

Eu verifico o túnel funciona com nc program e ~# characker no servidor. Verifico que tenho permissão para fazer solicitações http no ssh-server executando wget e lynx no servidor - ambos são executados sem erros.

Mas quando executo wget --no-proxy localhost:9999 no laptop, recebo o erro 403.

Eu posso fazer o mesmo usando ssh ssh-server 'wget -O - http://www.gnu.org/' >> whatever . Mas por que o túnel não funciona?

Então, quero esclarecer o que está acontecendo e que tipo de coisas o proxy não permite.

Meu palpite é que o proxy impede especificamente que o cliente ssh faça solicitações http. É assim?

Se for assim - como o proxy distingue o ssh-client de outros programas? Pode distinguir um pedido enviado do ssh-client e um pedido de outro programa?

E quais são as formas comuns de "mascarar o ssh-client para outro programa" (ou outras maneiras de passar pelo proxy)?

PS Seria fantástico se alguém escrevesse o endereço de um servidor ssh livre aberto para testar o tunelamento ssh e outras coisas nos comentários. (Normalmente ssh-servers não permitem tunelamento de graça).

    

Answer 1

Você não configurou (ou tentou usar) um proxy HTTP, nem um túnel ssh. Em vez disso, você usou o encaminhamento de porta por ssh.

Encaminhar portas TCP não funciona para HTTP. Visitando um URL HTTP usa o domínio do URL em dois pontos diferentes. 1 - para encontrar o endereço IP para o envio de mensagens. 2 - para o cabeçalho do host na mensagem HTTP. Isso permite que um endereço IP exiba sites para vários domínios.

Portanto, quando você visitar http://localhost:9999/ , a mensagem HTTP incluirá uma linha de cabeçalho Host: localhost:9999 . O servidor da Web GNU não veicula um site chamado localhost:9999 e nega acesso (403).

(O 403 é spec-legal. Em teoria, 403 é um pouco indelicado e você deve preferir 400 com uma mensagem. Pessoalmente eu usei 403 em meu site DynDNS trivial. Não por segurança conforme a especificação, mas porque FORBIDDEN é um sinal tão bom e strong para a solução de problemas.Espero que seja strong o suficiente para negar a impressão de que meu servidor web interceptou o deles (em caso de cache DNS desatualizado, por exemplo).

A abordagem conveniente é usar a opção "encaminhamento dinâmico de porta" do SSH -D , que configura um proxy SOCKS. Infelizmente wget não tem uma opção para um proxy SOCKS ( curl faz embora).