¿Cómo hacer que el túnel SSH funcione en Macintosh OSX El Capitan?

Actualicé de Yosemite a El Capitán, pero ahora SSHparece que el túnel está roto. Antes de la actualización, podría hacer un túnel en mi sesión de VNC desde otra computadora usando la aplicación SSH Tunnel Manager, pero después de la actualización, ahora solo se conecta nuevamente. También probé un comando manual desde un shell:

ssh -p 22 -R 5917:host-centos5x32:5917 user@router.example.com

El ssh se conecta, pero Real VNC v5.0.4 no puede mostrar la pantalla en la pantalla 17 de VNC con el error en un cuadro de diálogo (la única opción es correcta):

VNC Viewer
connect: Connection refused (61)

Ambas formas de tunelización funcionaron bien en Yosemite, pero ahora siempre falla con El Capitán.

Aquí está el nivel 3 de verbosidad de ssh:

bash-3.2$ ssh -vvv -p 22 -R 5917:h3-centos4x32:5917 user@router.example.com
OpenSSH_6.9p1, LibreSSL 2.1.7
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug1: /etc/ssh/ssh_config line 102: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to router.example.com [10.1.10.20] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /Users/user/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/user/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/user/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/user/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/user/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/user/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/user/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/user/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4* compat 0x00000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to router.example.com:22 as 'user'
debug3: put_host_port: [router.example.com]:22
debug3: hostkeys_foreach: reading file "/Users/user/.ssh/known_hosts"
debug3: record_hostkey: found key type RSA in file /Users/user/.ssh/known_hosts:14
debug3: load_hostkeys: loaded 1 keys from [router.example.com]:22
debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-dss
debug2: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug1: kex: server->client aes128-ctr hmac-sha1 none
debug1: kex: client->server aes128-ctr hmac-sha1 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<7680<8192) sent
debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
debug2: bits set: 3081/6144
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: got SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: ssh-rsa SHA256:7TdkXSi5vgIvHcaSM9U+A/S+pMz+u+S2vWMA55T8Y6w
debug3: put_host_port: [10.1.10.20]:22
debug3: put_host_port: [router.example.com]:22
debug3: hostkeys_foreach: reading file "/Users/user/.ssh/known_hosts"
debug3: record_hostkey: found key type RSA in file /Users/user/.ssh/known_hosts:14
debug3: load_hostkeys: loaded 1 keys from [router.example.com]:22
debug3: hostkeys_foreach: reading file "/Users/user/.ssh/known_hosts"
debug3: record_hostkey: found key type RSA in file /Users/user/.ssh/known_hosts:14
debug3: load_hostkeys: loaded 1 keys from [10.1.10.20]:22
debug1: Host '[router.example.com]:22' is known and matches the RSA host key.
debug1: Found key in /Users/user/.ssh/known_hosts:14
debug2: bits set: 3090/6144
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /Users/user/.ssh/id_rsa (0x0),
debug2: key: /Users/user/.ssh/id_dsa (0x0),
debug2: key: /Users/user/.ssh/id_ecdsa (0x0),
debug2: key: /Users/user/.ssh/id_ed25519 (0x0),
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/user/.ssh/id_rsa
debug3: sign_and_send_pubkey: RSA SHA256:a+3AC5+LSZvVQGRjkcYmIG35SzhOs9kKPv+yy2T6T2o
debug2: we sent a publickey packet, wait for reply
debug1: Authentication succeeded (publickey).
Authenticated to router.example.com ([10.1.10.20]:22).
debug1: Remote connections from LOCALHOST:5917 forwarded to local address h3-centos4x32:5917
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.
debug1: remote forward success for: listen 5917, connect h3-centos4x32:5917
debug1: All remote forwarding requests processed
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug3: Ignored env SHELL
debug3: Ignored env TERM
debug3: Ignored env TMPDIR
debug3: Ignored env Apple_PubSub_Socket_Render
debug3: Ignored env EMACSDATA
debug3: Ignored env EMACSPATH
debug3: Ignored env USER
debug3: Ignored env EMACS
debug3: Ignored env SSH_AUTH_SOCK
debug3: Ignored env TERMCAP
debug3: Ignored env __CF_USER_TEXT_ENCODING
debug3: Ignored env COLUMNS
debug3: Ignored env PATH
debug3: Ignored env PWD
debug3: Ignored env XPC_FLAGS
debug3: Ignored env XPC_SERVICE_NAME
debug3: Ignored env EMACSLOADPATH
debug3: Ignored env SHLVL
debug3: Ignored env HOME
debug3: Ignored env LOGNAME
debug3: Ignored env INFOPATH
debug3: Ignored env DISPLAY
debug3: Ignored env INSIDE_EMACS
debug3: Ignored env EMACSDOC
debug3: Ignored env _
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0

Tenga en cuenta que puedo conectar mi VNC dentro de un Windows 10 que se ejecuta con Oracle VirtualBox VM en mi Macintosh OSX El Capitan como una solución alternativa y tunelización con masilla. También probé una implementación alternativa de ssh en Macintosh y tenía el mismo problema.

Actualización: ahora Mac da la siguiente advertencia, mientras que la VM de Windows dentro de la Mac continúa ssh y túnel correctamente:

Advertencia: el reenvío de puerto remoto falló para el puerto de escucha 5917

— WilliamKF
fuente

¿Alguien más ha reproducido este problema?

— WilliamKF

Para ser claros, está intentando reenviar desde el lado de destino ssh a su host local, ¿sí?

— Ram

@ Ram Sí, tengo un servidor VNC ejecutándose en la pantalla remota de la máquina 17 (puerto 5917) y quiero volver a hacer un túnel en mi host local: 17 para poder ver mi VNC en la máquina local.

— WilliamKF

Hago esto todo el día. Tengo un servidor remoto que quiero ver, lo instalo y configuro un túnel desde localhost: algún puerto al servidor remoto: VNC_listener-port. ¿Es esto lo que quieres?

— Ram

@Ram Exactamente, lo he estado haciendo durante años, luego dejó de funcionar una vez que me actualicé a El Capitan.

— WilliamKF

Primero resumiré su caso de uso tal como lo entiendo: desea enviar un ssh a un dispositivo perimetral (router.example.com) y configurar la regla de reenvío a través del túnel SSH que le permite VNC desde su cliente (el host que está iniciando) ssh from) a host-centos5x32: 5917 donde tiene un servidor VNC escuchando.

Lo que ha configurado es una regla que reenviará desde el servidor ssh (router.example.com) al host de destino (host-centos5x32).

En su lugar, usaría este comando ssh: ssh -L 5917: host-centos5x32: 5917 user@router.example.com

Dejé caer -p 22 ya que ese es el valor predeterminado y cambié su regla -R (escuche en el destino y reenvíe según lo especificado) a una regla -L (escuche en mi host local y reenvíe según lo especificado). Cuando está activo, puede conectarse a localhost: 5917 (o localhost display 18) y se enrutará como se esperaba. Puede ser más sencillo diagnosticar esto usando 'telnet localhost: 5917' o 'nc localhost 5917', VNC responderá con algo como "RFB 003.008".

— RAM
fuente

Cambiando -Ra -Larreglado, :-) Me pregunto por qué funcionó esto usando -Rversiones anteriores de Mac OS X.

— WilliamKF

No estoy seguro de si todavía tiene un problema o no tiene una solución alternativa para su Mac, pero después de descubrir el mismo problema, descubrí que podía usar RealVNC y vincular mi puerto localhost en una sesión de terminal al puerto de destino .

ssh -L 5902: localhost: 5901 nombre de host

La sintaxis para el argumento es [bind_address:]port:host:hostport.

Luego dirija su sesión de VNC localhost:2.

— Flujo
fuente