Algo en MacOS Catalina (10.15.1) está interfiriendo con el reenvío de puertos ssh (necesario para la depuración de localhost y el desarrollo contra un sistema de servidor web desplegado en AWS).
Supongo que algo con las funciones de seguridad mejoradas, pero he sido incapaz de averiguar qué buscando y curioseando.
El túnel parece arrancar bien, pero cuando un cliente intenta conectarse la conexión es denegada. Los comandos de inicio del túnel y de la aplicación son los mismos que funcionaban bien en todas las versiones anteriores del sistema operativo, según parece, pero están fallando en esta nueva instalación 10.15 (nada portado, una nueva configuración de herramientas. He cambiado mi shell por defecto de nuevo a bash .)
Configuración de la red: Hay un servidor de redis en una VPC de AWS que no es enrutable públicamente. Tenemos un servidor de bastión que es públicamente enrutable que puede reenviar la conexión a través de ssh. Puedo conectarme al servidor del bastión para una sesión interactiva, por lo que las claves y las frases de paso están bien hasta donde yo sé. No hay VPN a AWS, por lo que el host bastión es la única manera de entrar en las subredes privadas.
Este es el comando que utilizamos para iniciar el túnel ( prodbastion se define en .ssh/config ):
ssh -v -N -L 6399:redis.<HOSTNAME>:6379 prodbastion
Esto registra verbosamente en el shell, aquí está el final del inicio de la autenticación supuestamente exitosa, seguido por las repetidas fallas de conexión del cliente
debug1: Authentication succeeded (publickey).
Authenticated to <bastionprod hostname> ([<bastion prod ip>]:22).
debug1: Local connections to LOCALHOST:6399 forwarded to remote address redis.<HOSTNAME>:6379
debug1: Local forwarding listening on ::1 port 6399.
debug1: channel 0: new [port listener]
debug1: Local forwarding listening on 127.0.0.1 port 6399.
debug1: channel 1: new [port listener]
...
debug1: channel 2: free: direct-tcpip: listening port 6399 for redis.<HOSTNAME> port 6379, connect from 127.0.0.1 port 51454 to 127.0.0.1 port 6399, nchannels 3
debug1: Connection to port 6399 forwarding to redis.<HOSTNAME> port 6379 requested.
debug1: channel 2: new [direct-tcpip]
channel 2: open failed: administratively prohibited: open failed
debug1: channel 2: free: direct-tcpip: listening port 6399 for redis.<HOSTNAME> port 6379, connect from 127.0.0.1 port 51457 to 127.0.0.1 port 6399, nchannels 3
debug1: Connection to port 6399 forwarding to redis.<HOSTNAME> port 6379 requested.
debug1: channel 2: new [direct-tcpip]
...El cliente es una aplicación web nodejs, que necesita datos de redis. los registros allí sólo dicen más o menos no se puede conectar:
2019-12-09T17:13:51.286Z - info: Client Redis connection: {"host":"localhost","port":"6399","database":"4"}
2019-12-09T17:13:51.299Z - info: mongoose connected
2019-12-09T17:13:51.332Z - error: Redis error occured: AbortError: Ready check failed: Redis connection lost and command aborted. It might have been processed.
2019-12-09T17:13:51.473Z - error: Redis error occured: AbortError: Ready check failed: Redis connection lost and command aborted. It might have been processed.
...Parece que tiene el mismo fallo con el sistema ssh o openssh instalado con brew.
Actualización en respuesta a las preguntas:
- Fue mi error todo el tiempo, el nombre de host en el comando del túnel no existía pero mi historial de bash me hizo creer que sí
- el cortafuegos estaba desactivado
- telnet no pudo conectarse a 6399 con el túnel hasta un nombre de host malo
- telnet (y nuestra aplicación que utiliza redis) podría conectarse con el nombre de host correcto.
- ¡argh y perdón por la confusión!
