1

I upgraded from Yosemite to El Capitan, but now SSH tunneling appears to be broken. Before upgrade, I could tunnel my VNC session from another computer using the app SSH Tunnel Manager, but after upgrade, it now just goes into a loop reconnecting. I also tried a manual command from a shell:

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

The ssh connects, but Real VNC v5.0.4 fails to bring up the display on VNC display 17 with the error in a dialog (only choice is OK):

VNC Viewer
connect: Connection refused (61)

Both ways of tunneling worked fine in Yosemite, but now always fails with El Capitan.


Here is the level 3 verbosity out of 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

Note that I am able to connect my VNC inside a Windows 10 running with Oracle VirtualBox VM on my Macintosh OSX El Capitan as a work around and tunneling with putty. I also tried an alternate implementation of ssh on the Macintosh and it had the same issue.


Update: Now Mac gives the following warning, while the Windows VM inside the Mac continues to ssh and tunnel properly:

Warning: remote port forwarding failed for listen port 5917

  • Has anyone else reproduced this issue? – WilliamKF Nov 2 '15 at 16:23
  • To be clear, you are trying to forward from the ssh destination side back to your local host yes? – Ram Feb 1 '16 at 18:11
  • @Ram Yes, I have a VNC server running on remote machine display 17 (port 5917) and I want to tunnel it back to my localhost:17 so I can view my VNC on local machine. – WilliamKF Feb 1 '16 at 19:30
  • I do this all day long. I have a remote server I want to view, I ssh to it and setup a tunnel from localhost:someport to remote server:VNC_listener-port. Is this what you want? – Ram Feb 2 '16 at 16:31
  • @Ram Exactly, I've been doing it for years, then it stopped working once I upgraded to El Capitan. – WilliamKF Feb 2 '16 at 19:00
2

First I'll summarize your use case as I understand it: You want to ssh to an edge device (router.example.com) and setup forwarding rule through the SSH tunnel that allows you to VNC from your client (the host you are initiating ssh from) to host-centos5x32:5917 where you have a VNC server listening.

What you have setup is a rule which will forward from the ssh server (router.example.com) to the target host (host-centos5x32).

I would use this ssh command instead: ssh -L 5917:host-centos5x32:5917 user@router.example.com

I dropped -p 22 since that's the default and I changed your -R rule (listen on destination and forward on as specified) to a -L rule (listen on my local host and forward as specified). When this is active you can vnc to localhost:5917 (or localhost display 18) and it will route as expected. It might be simpler to diagnose this using 'telnet localhost:5917' or 'nc localhost 5917', VNC will respond with something like "RFB 003.008".

  • Changing -R to -L fixed it, :-) I wonder why this worked using -R in prior Mac OS X releases? – WilliamKF Feb 3 '16 at 21:09
0

Not sure if you're still having an issue or don't have a work around for your Mac, but after discovering the same issue I found I was able to just use RealVNC and bind my localhost port in a terminal session to the destination port.

ssh -L 5902:localhost:5901 hostname

The syntax for the argument is [bind_address:]port:host:hostport.

Then direct your VNC session localhost:2.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.