ssh tunnel - bind: no se puede asignar la dirección solicitada


26

Intentando crear un túnel ssh socks (-D) - Linux box a Linux box (ambos centos):

sshd ejecutándose en el lado remoto ok.

Desde la máquina local hacemos / vemos esto:

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

(donde 8.8.8.8 es realmente la IP de mi servidor y 'usuario' es mi nombre de usuario real)

He iniciado sesión en el lado remoto en esta ventana de terminal. Puedo verificar que el puerto local no se usó antes de este comando, y luego lo usó un proceso ssh, después del comando, a través de:

netstat -lnp | grep 1080

Entonces, a diferencia de la mayoría de las respuestas en Google con este error, el problema no parece ser la asignación de la interfaz de bucle invertido. Si trato de usar este túnel con un cliente de correo, el lado local permite el intento (sin error de 'error de proxy'), pero no se devuelve ningún dato / respuesta.

En el lado remoto, tengo "PermitTunnel yes" en mi sshd_config (aunque 'yes' debería ser el predeterminado, de todos modos).

Ideas o pistas?

Aquí está la salida de depuración 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

Otra pista: si ejecuto un Virtual Box en el cliente que ejecuta Windows, abro un túnel con masilla en ese cuadro, ese túnel, al mismo servidor remoto, funciona.

Más extraño aún "Si uso Putty (para Linux) ejecutándose directamente en el Cliente Linux, NO funciona, incluso si la configuración es un duplicado exacto de la configuración de masilla que FUNCIONA en Putty ejecutándose en Windows en un Virtual Box en el mismo ¿Máquina del cliente? Hay algo sospechoso ... todavía estoy intentando experimentar para descubrir qué es.


¿Qué pasa si intentas forzarlo a usar ipv4? (solo como una prueba de resolución de problemas inicial). Por ejemplo ssh -4 -D 1080 user@8.8.8.8
Fred Clausen el

¿Puedes probar un número de puerto más alto, 4000?
jwbensley

Gracias por los aportes. Lo tengo para trabajar con: ssh -4 -D 8081 user@8.8.8.8
JosephK

Respuestas:


41

El cierre del bucle aquí. La respuesta, en este caso, fue forzar al cliente ssh a usar ipv4. P.ej

ssh -4 -D 8081 user@8.8.8.8

Entonces pensaría, excepto que puedo seleccionar 'force ip4' en masilla (ejecutándose en Linux) sin éxito. También IPV6 está deshabilitado en esta máquina, por lo que teóricamente no debería haber estado en juego. Los resultados completamente inconsistentes que sigo probando diferentes permutaciones de esta cosa me dejan rascándome la cabeza. En cualquier caso, su respuesta me ayudó a hacerlo funcionar, y tal vez ha descubierto algo extraño sobre cómo está funcionando esta versión de CentOS o Linux Kernel o algo así. Gracias.
JosephK

Una posibilidad remota, pero tal vez desactivar la resolución SSH DNS en el servidor, "UseDNS no" en sshd_config, podría resolverlo. Quizás haya una resolución DNS extraña en el servidor que causa problemas de enlace.
Fred Clausen

1
Muchas gracias, el -4 también fue la solución para Ubuntu 11.04.
Sander

Comencé a tener este problema después de actualizar a Ubuntu 13.04, y esta fue la solución.
Nick

1
En lugar de tener que especificar -4 cada vez, suponiendo que todas las conexiones ssh se realicen solo con IPv4, agregue "AddressFamily inet" a su archivo ssh_config, por usuario en $ {HOME} /. Ssh / ssh_config, o en todo el sistema para todos los usuarios en / etc / ssh / ssh_config
JG Miller
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.