ssh-tunneled recusas de conexão de proxy SOCKS no Firefox 47.0 / Kubuntu 16.04

Question

Estou com dificuldades para fazer conexões com sites usando o Firefox em um proxy SOCKS encapsulado. SOCKS4 / SOCKS5 não faz diferença.

Eu configurei o túnel com

  

ssh -D 1234 [email protected]

em seguida, aponte o proxy SOCKS do Firefox para localhost em tcp / 1234.

Um ponto importante a ser observado aqui é que o túnel que estou configurando está em um servidor remoto que tenho usado para esse propósito por muitos anos. Eu tenho proxies FF e outros navegadores através dele para muitos milhares de sessões em uma dúzia ou mais de diferentes plataformas em todos os principais sistemas operacionais. Uma vez que eu funciono, sempre funciona bem. No entanto, nesta instância particular do FF, tenho problemas estranhos e intermitentes.

O problema é que o FF não parece "querer" estabelecer uma conexão. Eu digito uma URL ou clico em um link e eu instantaneamente recebo "Não é possível conectar" / "O Firefox não consegue estabelecer uma conexão com o servidor em ..." Quando eu digo "instantaneamente", eu significa que isso volta para mim em uma pequena fração de segundo.

Então, clico em "Tentar novamente" ou na pequena seta de recarga. E faço isso de novo, de novo e de novo, o mais rápido que posso. E depois de algumas tentativas - às vezes 3-4, às vezes até 15-20 - recebo uma conexão e tudo funciona! Então a conexão tunnel / SOCKS está disponível, é só que o FF se recusa a usá-lo até que seja intimidado a fazê-lo. Depois que eu obtiver uma conexão, mais recargas não farão com que ela seja perdida.

Eu tenho alguns add-ons, mas a) Eu os desabilitei seletivamente sem ajuda, e b) Eu (é claro) tentei o safe-mode. Não há mudanças.

Alguma sugestão?

    

Answer 1

Infelizmente, esse problema é intermitente e isso confundiu meus esforços de solução de problemas. A resposta que o @Terrance deu acima, que eu marquei como A Resposta, na verdade não é uma solução para o problema para mim. parecia funcionar, e na verdade funcionou por um tempo. Então eu me deparei com problemas novamente. Às vezes, parar minha sessão ssh e reiniciá-la curaria o problema - por enquanto - e às vezes a reinicialização não faria diferença.

A sugestão mencionada este segmento em outro lugar - ou seja, para especificar 127.0.0.1 em vez de "localhost "nas configurações de proxy do browser - da mesma forma, parecia fazer a diferença, mas acabou sendo ineficaz. Eu respondi anteriormente que esta era a diferença crítica entre as conexões do navegador funcionando e não funcionando, mas novamente isso foi prematuro. Eu continuei a experimentar problemas intermitentes na capacidade do meu navegador de fazer conexões com sites através do túnel.

Agora obtive experiência adicional suficiente com esse problema e a solução que mencionei abaixo é que estou razoavelmente confiante em minha conclusão de que existe um tipo de erro de tempo curto no próprio OpenSSH . BTW, minha versão é

  

OpenSSH_7.2p2 Ubuntu-4ubuntu1, OpenSSL 1.0.2g-fips 1 de março de 2016

Eu baseio isso em a) o fato de que o problema é claramente independente do navegador (verificado no Firefox, Chromium e w3m) eb) o fato de que usar um cliente ssh alternativo curou o problema de forma confiável.

Eu baixei a fonte e construí e instalei o PuTTY (de este link ) . NOTA: certifique-se de instalar o pacote virtual gtkgl-dev para que a fonte PuTTY possa encontrar os arquivos de cabeçalho. Depois, configurei-o exatamente como fiz no Windows tantas vezes no passado, e ele já está funcionando há dois dias. Falhas ZERO.

Estou confiante de que esta é a correção e que há um bug no OpenSSH atual. Eu vou trabalhar em fazer um relatório para esse efeito.

Eu estou selecionando minha própria resposta como A Resposta para os propósitos desta pergunta, embora a resposta do @ Terrence acima ainda seja uma leitura muito útil.

    

Answer 2

Eu tenho que usar um proxy todos os dias no trabalho para se conectar a servidores do outro lado de um firewall. Eu também uso o Firefox, o Chrome e o Ubuntu 16.04.

EDIT: Esqueci uma parte disso. Eu tive que adicionar um tempo limite para um arquivo de configuração ssh ou o meu túnel irá tempo limite e eu perco minha conexão. Depois de adicionar as seguintes informações, minha conexão permanece aberta:

Em ~/.ssh/config adicione as seguintes informações ( se o arquivo não existir, crie-o. ). Isso enviará um servidor keepalive para o seu túnel a cada 15 segundos.

Host *
ServerAliveInterval 15

Eu abro minha conexão de túnel com o seguinte comando:

ssh -CfND 1234 username@proxyhost

Em seguida, no Firefox, nas Configurações de conexão na Configuração de proxy manual , preenho somente o host SOCKS: com 127.0.0.1 e < strong> Porta: 1234. Depois, certifico-me de que o SOCKS v5 está selecionado. Observe também que não tenho nada na caixa Sem proxy para:

Eu consigo me conectar aos meus hosts dessa maneira sem problemas.

Em seguida, para o Google Chrome, executo uma linha de comando para não precisar definir as configurações para o Google Chrome sempre que quiser usar o proxy, e, em seguida, nenhum proxy. Para conectar o Chrome ao proxy, eu corro a seguinte linha:

nohup google-chrome-stable --proxy-server="socks5://127.0.0.1:1234" & > /dev/null 2>&1

from ssh manpage

 -C      Requests compression of all data (including stdin, stdout,
         stderr, and data for forwarded X11, TCP and UNIX-domain connec‐
         tions).  The compression algorithm is the same used by gzip(1),
         and the “level” can be controlled by the CompressionLevel option
         for protocol version 1.  Compression is desirable on modem lines
         and other slow connections, but will only slow down things on
         fast networks.  The default value can be set on a host-by-host
         basis in the configuration files; see the Compression option.

 -f      Requests ssh to go to background just before command execution.
         This is useful if ssh is going to ask for passwords or
         passphrases, but the user wants it in the background.  This
         implies -n.  The recommended way to start X11 programs at a
         remote site is with something like ssh -f host xterm.

 -N      Do not execute a remote command.  This is useful for just for‐
         warding ports.

 -D [bind_address:]port
         Specifies a local “dynamic” application-level port forwarding.
         This works by allocating a socket to listen to port on the local
         side, optionally bound to the specified bind_address.  Whenever a
         connection is made to this port, the connection is forwarded over
         the secure channel, and the application protocol is then used to
         determine where to connect to from the remote machine.  Currently
         the SOCKS4 and SOCKS5 protocols are supported, and ssh will act
         as a SOCKS server.  Only root can forward privileged ports.
         Dynamic port forwardings can also be specified in the configura‐
         tion file.

Espero que isso ajude!