túnel ssh que rechaza las conexiones con "canal 2: error de apertura"

De repente (léase: sin cambiar ningún parámetro) mi netbsd virtualmachine comenzó a actuar de manera extraña. Los síntomas se refieren a túneles ssh.

Desde mi laptop lanzo:

$ ssh -L 7000:localhost:7000 user@host -N -v

Luego, en otro caparazón:

$ irssi -c localhost -p 7000

La depuración ssh dice:

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

Intenté también con localhost: 80 conectarse al servidor web (remoto), con resultados idénticos.

El host remoto ejecuta 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

Estoy un poco perdido Intenté ejecutar tcpdumpen el host remoto, y vi estos 'chksum malos':

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>

Traté de reiniciar el demonio ssh en vano. Todavía no he reiniciado, tal vez alguien aquí pueda sugerir otros diagnósticos. Creo que podría ser el controlador de la tarjeta de red virtual o alguien rooteó nuestro ssh.

Ideas ..?

Problema resuelto:

$ ssh -L 7000:127.0.0.1:7000 user@host -N -v -v

... aparentemente, ' host local ' no era del agrado del host remoto. Sin embargo, el control remoto /etc/hostscontiene:

::1                     localhost localhost.
127.0.0.1               localhost localhost.

mientras que la interfaz de red local es

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33184
        inet 127.0.0.1 netmask 0xff000000
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2

Suspiro. tanto por la generosidad de 100rp que puse :)

Aunque el problema de OP ya se resolvió, decidí compartir la solución para mi problema, porque recibí el mismo mensaje de error de ssh y no encontré ninguna solución en otros sitios.

En mi caso, tuve que conectarme al servicio que solo escucha en IPv6. Lo intenté:

ssh -f root@192.168.0.18 -L 51005: 127.0.0.1: 51005 -N
ssh -f root@192.168.0.18 -L 51005: localhost: 51005 -N

y algunas otras formas pero no funcionó. Cualquier intento de conexión a http://localhost:51005causa errores como este: channel 2: open failed: connect failed: Connection refused

La solucion es:

ssh -f root@192.168.0.18 -L 51005: [:: 1]: 51005 -N

La dirección IPv6 debe estar entre corchetes.

Primero intentaría esto.

$ ssh -L 7000:127.0.0.1:7000 user@host -N -v -v

Puede usar "-v" hasta 3 veces para aumentar la verbosidad.

Creo que este mensaje de error puede surgir si un firewall bloquea el puerto 7000, pero ya lo ha descartado. (Si los lectores posteriores no lo han descartado, mire la salida de netstat --numeric-ports).

Yo creo que podría haber visto este mensaje de error hace mucho tiempo, cuando ssh tenido conocimiento de las direcciones IPv6 después de una actualización. Podría estar equivocado sobre eso. Si tiene ganas de experimentar, puede probar la dirección de bucle invertido IPV6 "0: 0: 0: 0: 0: 0: 0: 1" (o ":: 1").

"... aparentemente, 'host local' no era del agrado del host remoto. Sin embargo, remoto / etc / hosts contiene:"

Excepto que estaba ejecutando ssh en el cliente, por lo que 'localhost' no fue del agrado de su cliente. El archivo remoto / etc / hosts es para los de conexión remota a cabo no entrantes conexiones.

Encontré este mismo error al intentar conectarme a mysql en otro servidor a través de un túnel ssh. Descubrí que el parámetro bind-address en /etc/my.cnf en el servidor de destino estaba vinculado a mi ip externa (servidor NIC dual) en lugar de interna, para lo cual no tenía uso.

Cuando configuré bind-address = 127.0.0.1, pude usar con éxito mi túnel ssh de la siguiente manera:

ssh -N -f -L 3307:127.0.0.1:3306 user@server.name

mysql -h 127.0.0.1 --port=3307 --protocol=TCP -uusername -ppassword

Encontré este error cuando reenviaba puertos con un nombre de dominio completo en lugar de localhost:

ssh -L 5900:host.name.com:5900 x11vnc

El puerto se estaba abriendo solo para localhost, por lo que para aceptar conexiones con un nombre completamente calificado, tuve que agregar una descripción de puerto vinculante :

ssh -L *:5900:host.name.com:5900 x11vnc

lo que permitiría conexiones desde cualquier lugar (por lo que no es tan seguro, úselo con moderación).

Para mí, agregar ":" funciona de manera que el comando en su caso se vería así:

ssh -L :7000:localhost:7000 user@host -N -v

???

canal 2: error al abrir: error al conectar: ​​conexión rechazada

No user@hosthay nada que escuche el puerto 7000, eso es simple y eso es todo.

Recibí el mismo mensaje de error:

canal 3: error al abrir: error al conectar: ​​conexión rechazada

Y la causa fue un error humano: yo tratando de acceder a un puerto diferente en el host remoto que el que especifiqué.

Solo pensé en compartirlo, aunque probablemente esta no sea la razón por la cual la mayoría de ustedes está experimentando este error.

Para mí, estaba intentando ssh -L <port>:<remote server IP>:<port> <login>@<remote server IP>cuando debería haber estado haciendo ssh -L <port>:127.0.0.1:<port> <login>@<remote server IP>.

¡Espero que esto ayude a alguien!

La interpretación alternativa es, en mi caso, que estás escribiendo mal.

user@host ~ $ ssh -vvvNL 4444:127.0.0.0.1:4444
...
channel 2: open failed: connect failed: Name or service not known

Lo que sucede aquí es que la dirección IP tiene demasiados ceros, por lo que no es una dirección válida. Entonces, ssh lo trata como un nombre de dominio que no puede resolver. ¡Uy!

PD: Complemento esto para que tengamos una lista completa de posibles problemas al solucionar los mismos síntomas.