SSH Tunneling De repente não funciona

Question

Eu tenho um computador doméstico rodando o Ubuntu 12.10.

Para garantir que meus dados não sejam monitorados em público, eu usei anteriormente um serviço de VPN por assinatura.

Eu decidi pesquisar alternativas e descobri que o OpenSSH facilita bastante a criação de um proxy SOCKS que pode ser usado com o Firefox e o PuTTy.

Depois de muita tentativa e erro, eu finalmente tenho um servidor que eu posso conectar remotamente e usar comandos BASH. (Eu tive que usar a porta 80 para o servidor SSH, pois muitos lugares bloquearam o tráfego através das "portas usuais" "como 22.)

O problema real veio quando tentei usar isso como proxy.

Eu usei PuTTy e fui para a seção SSH Tunnels e adicionei uma Dynamic Forwarded Port e configurei a porta para 80. Fui então para o Firefox e selecionei o SOCKS v5, 127.0.0.1 como o endereço IP e a porta como 80. Isso pareceu funcionar perfeitamente e uma consulta do Google "o que é meu ip" retornou o endereço IP residencial correto, mas ele parou de funcionar.

O próprio shell continuou a funcionar e eu o usei para redefinir o servidor SSH doméstico sem sucesso. Eu não tenho absolutamente nenhum indício do que está indo errado e qualquer ajuda será muito apreciada.

Se precisar de mais informações, terei prazer em fornecê-la.

    

Answer 1

Eu tive um problema semelhante ao usar o ssh no GNU / Linux. Não sei se está relacionado, mas no final o efeito é o mesmo, não consegui encontrar nenhuma resposta na net e este foi o resultado da pesquisa, então decidi contribuir com a minha solução.

No meu caso, eu estava executando isso:

ssh -C2qTnN -D 127.0.0.1:3128 [email protected]

para abrir um proxy de túnel SOCKS e o comando estava em um script bash.

O problema e a solução: Fiz o túnel usando um usuário do Linux e suas chaves ssh e estava tentando se conectar usando outro usuário. O comando ssh foi executado em segundo plano, então não consegui ver se ele estava me pedindo autenticação. Anexar a chave pública do novo usuário local de ~/.ssh/id_rsa.pub ao servidor remoto em /home/user/.ssh/authorized_keys resolveu o problema.

Nota: O arquivo authorized_keys do servidor remoto deve ser somente leitura em alguns sistemas, portanto, se você criar esse arquivo, execute chmod 400 authorized_keys porque algumas configurações do servidor ssh recusarão a leitura se alguém tiver permissões de gravação .