De repente (leia-se: sem alterar nenhum parâmetro), minha máquina virtual netbsd começou a agir de forma estranha. Os sintomas dizem respeito ao tunelamento ssh.
Do meu laptop eu lanço:
$ ssh -L 7000:localhost:7000 user@host -N -v
Então, em outro shell:
$ irssi -c localhost -p 7000
A depuração ssh diz:
debug1: Connection to port 7000 forwarding to localhost port 7000 requested.
debug1: channel 2: new [direct-tcpip]
channel 2: open failed: connect failed: Connection refused
debug1: channel 2: free: direct-tcpip: listening port 7000 for localhost port 7000, connect from 127.0.0.1 port 53954, nchannels 3
Tentei também com localhost:80 conectar ao servidor web (remoto), com resultados idênticos.
O host remoto executa o NetBSD:
bash-4.2# uname -a
NetBSD host 5.1_STABLE NetBSD 5.1_STABLE (XEN3PAE_DOMU) #6: Fri Nov 4 16:56:31 MET 2011 root@youll-thank-me-later:/m/obj/m/src/sys/arch/i386/compile/XEN3PAE_DOMU i386
Estou um pouco perdido. Tentei executar tcpdumpno host remoto e localizei esses 'chksum ruins':
09:25:55.823849 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 67, bad cksum 0 (->3cb3)!) 127.0.0.1.54381 > 127.0.0.1.7000: P, cksum 0xfe37 (incorrect (-> 0xa801), 1622402406:1622402421(15) ack 1635127887 win 4096 <nop,nop,timestamp 5002727 5002603>
Eu tentei reiniciar o daemon ssh sem sucesso. Ainda não reiniciei - talvez alguém aqui possa sugerir outros diagnósticos. Acho que pode ser o driver da placa de rede virtual ou alguém enraizou nosso ssh.
Ideias..?
Problema resolvido:
...aparentemente, ' localhost ' não foi apreciado pelo host remoto. No entanto, o controle remoto
/etc/hostscontém:enquanto a interface de rede local estiver
Suspirar. tanto pela recompensa de 100rp que coloquei :)
Embora o problema do OP já tenha sido resolvido, decidi compartilhar a solução para o meu problema, pois recebi a mesma mensagem de erro do ssh e não encontrei nenhuma solução em outros sites.
No meu caso tive que me conectar ao serviço que escuta apenas no IPv6. Eu tentei:
e algumas outras maneiras, mas não funcionou. Qualquer tentativa de conexão
http://localhost:51005causa erros como este:channel 2: open failed: connect failed: Connection refusedA solução é:
O endereço IPv6 deve estar entre colchetes.
Eu tentaria isso primeiro.
Você pode usar "-v" até 3 vezes para aumentar a verbosidade.
Acho que essa mensagem de erro pode surgir se um firewall bloquear a porta 7000, mas você já havia descartado isso. (Se os leitores posteriores não descartaram isso, veja a saída de
netstat --numeric-ports.)Acho que posso ter visto essa mensagem de erro há muito tempo, quando o ssh tomou conhecimento dos endereços IPV6 após uma atualização. Eu posso estar errado sobre isso. Se você quiser experimentar, tente o endereço de loopback IPV6 "0:0:0:0:0:0:0:1" (ou "::1").
"...aparentemente, 'localhost' não foi apreciado pelo host remoto. No entanto, /etc/hosts remoto contém:"
Exceto que você estava executando ssh no cliente, então 'localhost' não foi apreciado pelo seu cliente. O arquivo /etc/hosts remoto é para a conexão remota e não para as conexões de entrada .
Para mim, adicionar ":" à esquerda funciona, então o comando no seu caso ficaria assim:
Eu encontrei esse mesmo erro ao tentar conectar ao mysql em outro servidor por meio de um túnel ssh. Descobri que o parâmetro de endereço de ligação em /etc/my.cnf no servidor de destino estava vinculado ao meu ip externo (servidor de NIC duplo) em vez de interno, para o qual eu não tinha uso.
Quando defino o endereço de ligação = 127.0.0.1, pude usar com êxito meu túnel ssh da seguinte maneira:
Encontrei este erro quando estava encaminhando portas com um nome de domínio completo em vez de localhost:
A porta estava sendo aberta apenas para localhost, portanto, para aceitar conexões com um nome totalmente qualificado, tive que adicionar uma descrição de porta de ligação :
o que permitiria conexões de qualquer lugar (portanto, não é tão seguro, use-o com moderação).
???
Em
user@hostnão há nada escutando a porta 7000, isso é simples e isso é tudo.Interpretação alternativa é, no meu caso, você digitar errado.
O que acontece aqui é que o endereço IP tem um zero a mais, não sendo um endereço válido. Portanto, o ssh o trata como um nome de domínio que não pode ser resolvido. Ops!
PS: Eu complemento isso para que tenhamos uma lista abrangente de possíveis problemas ao solucionar os mesmos sintomas.
Recebi a mesma mensagem de erro:
E a causa foi um erro humano - eu tentando acessar uma porta diferente no host remoto que eu especifiquei.
Apenas pensei em compartilhar isso, embora essa provavelmente não seja a razão pela qual a maioria de vocês está enfrentando esse erro.