ssh tunnel - bind: não é possível atribuir o endereço solicitado

Tentando criar um túnel de meias (-D) ssh - caixa do Linux para a caixa do Linux (ambos os centos):

sshd rodando no lado remoto ok.

Na máquina local, fazemos / vemos isso:

ssh -D 1080 user@8.8.8.8.
user@8.8.8.8's password: 
bind: Cannot assign requested address

(onde 8.8.8.8 é realmente o IP do meu servidor e 'usuário' é o meu nome de usuário real)

Estou logado no lado remoto nesta janela do terminal. Posso verificar se a porta local não foi utilizada antes deste comando e, em seguida, usada por um processo ssh, após o comando, via:

netstat -lnp | grep 1080

Portanto, diferentemente da maioria das respostas do Google com esse erro, o problema não parece ser a atribuição da interface de loopback. Se eu tentar usar esse encapsulamento com um cliente de email, o local permitirá a tentativa (nenhum erro 'falhou no proxy'), mas nenhum dado / resposta será retornado.

No lado remoto, eu tenho "PermitTunnel yes" no meu sshd_config (embora 'yes' deva ser o padrão, de qualquer maneira).

Idéias ou pistas?

Aqui está a saída de depuração relevante

OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *

....

debug1: Authentication succeeded (password).
debug1: Local connections to LOCALHOST:1080 forwarded to remote address socks:0
debug1: Local forwarding listening on 127.0.0.1 port 1080.
debug1: channel 0: new [port listener]
debug1: Local forwarding listening on ::1 port 1080.
bind: Cannot assign requested address
debug1: channel 1: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.utf8

Outra pista: se eu executar uma Caixa Virtual no cliente executando o Windows, abra um túnel com massa nessa caixa, para que o túnel, no mesmo servidor remoto, funcione.

Ainda mais estranho "Se eu usar o Putty (para linux) em execução diretamente no cliente Linux, ele NÃO funcionará, mesmo que as configurações sejam uma duplicata exata das configurações de massa que FUNCIONAM no Putty em execução no Windows em uma caixa virtual da mesma forma. Máquina cliente? Há algo suspeito ... ainda tentando experimentos para descobrir o que é.

linux ssh tunnel

— JosephK
fonte

E se você tentar forçá-lo a usar o ipv4? (apenas como um teste inicial de solução de problemas). Por exemplo ssh -4 -D 1080 user@8.8.8.8

— Fred Clausen

Você pode tentar um número de porta maior, 4000?

— #

Obrigado por contribuições. Eu consegui trabalhar com: ssh -4 -D 8081 user@8.8.8.8

— JosephK:

O fim do ciclo aqui. A resposta, nesse caso, foi forçar o cliente ssh a usar o ipv4. Por exemplo

ssh -4 -D 8081 user@8.8.8.8

— Fred Clausen
fonte

Então, eu pensaria, exceto que eu posso selecionar 'force ip4' na massa (executando no Linux) sem sucesso. O IPV6 também está desativado nesta máquina, portanto, teoricamente, não deveria estar em jogo. Os resultados completamente inconsistentes que continuo tentando diferentes permutações dessa coisa me fazem coçar a cabeça. De qualquer forma, sua resposta me ajudou a fazê-lo funcionar e talvez tenha descoberto algo estranho sobre como esta versão do CentOS ou Linux Kernel ou algo parecido está funcionando - Obrigado.

— JosephK

Um tiro no escuro, mas talvez desativando a resolução DNS SSH no servidor, "UseDNS no" em sshd_config, pode resolvê-lo. Talvez alguma resolução estranha de DNS esteja ocorrendo no servidor, causando problemas de ligação.

— 11119

Muito obrigado, o -4 também foi a solução para o Ubuntu 11.04.

— Sander

Comecei a ter esse problema depois de atualizar para o Ubuntu 13.04, e essa foi a correção.

— Nick

Em vez de especificar -4 sempre, assumindo que todas as conexões ssh devem ser feitas apenas com IPv4, adicione "AddressFamily inet" ao seu arquivo ssh_config - por usuário em $ {HOME} /. Ssh / ssh_config ou em todo o sistema para todos os usuários em / etc / ssh / ssh_config

— JG Miller