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 Viewerconnect: 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.comOpenSSH_6.9p1, LibreSSL 2.1.7debug1: Reading configuration data /etc/ssh/ssh_configdebug1: /etc/ssh/ssh_config line 20: Applying options for *debug1: /etc/ssh/ssh_config line 102: Applying options for *debug2: ssh_connect: needpriv 0debug1: Connecting to router.example.com [10.1.10.20] port 22.debug1: Connection established.debug1: key_load_public: No such file or directorydebug1: identity file /Users/user/.ssh/id_rsa type -1debug1: key_load_public: No such file or directorydebug1: identity file /Users/user/.ssh/id_rsa-cert type -1debug1: key_load_public: No such file or directorydebug1: identity file /Users/user/.ssh/id_dsa type -1debug1: key_load_public: No such file or directorydebug1: identity file /Users/user/.ssh/id_dsa-cert type -1debug1: key_load_public: No such file or directorydebug1: identity file /Users/user/.ssh/id_ecdsa type -1debug1: key_load_public: No such file or directorydebug1: identity file /Users/user/.ssh/id_ecdsa-cert type -1debug1: key_load_public: No such file or directorydebug1: identity file /Users/user/.ssh/id_ed25519 type -1debug1: key_load_public: No such file or directorydebug1: identity file /Users/user/.ssh/id_ed25519-cert type -1debug1: Enabling compatibility mode for protocol 2.0debug1: Local version string SSH-2.0-OpenSSH_6.9debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3debug1: match: OpenSSH_4.3 pat OpenSSH_4* compat 0x00000000debug2: fd 3 setting O_NONBLOCKdebug1: Authenticating to router.example.com:22 as 'user'debug3: put_host_port: [router.example.com]:22debug3: hostkeys_foreach: reading file "/Users/user/.ssh/known_hosts"debug3: record_hostkey: found key type RSA in file /Users/user/.ssh/known_hosts:14debug3: load_hostkeys: loaded 1 keys from [router.example.com]:22debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsadebug1: SSH2_MSG_KEXINIT sentdebug1: SSH2_MSG_KEXINIT receiveddebug2: 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-sha1debug2: 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-dssdebug2: 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.sedebug2: 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.sedebug2: 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-96debug2: 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-96debug2: kex_parse_kexinit: none,zlib@openssh.com,zlibdebug2: kex_parse_kexinit: none,zlib@openssh.com,zlibdebug2: 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-sha1debug2: kex_parse_kexinit: ssh-rsa,ssh-dssdebug2: 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.sedebug2: 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.sedebug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96debug2: kex_parse_kexinit: none,zlib@openssh.comdebug2: kex_parse_kexinit: none,zlib@openssh.comdebug2: 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 nonedebug1: kex: client->server aes128-ctr hmac-sha1 nonedebug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<7680<8192) sentdebug1: got SSH2_MSG_KEX_DH_GEX_GROUPdebug2: bits set: 3081/6144debug1: SSH2_MSG_KEX_DH_GEX_INIT sentdebug1: got SSH2_MSG_KEX_DH_GEX_REPLYdebug1: Server host key: ssh-rsa SHA256:7TdkXSi5vgIvHcaSM9U+A/S+pMz+u+S2vWMA55T8Y6wdebug3: put_host_port: [10.1.10.20]:22debug3: put_host_port: [router.example.com]:22debug3: hostkeys_foreach: reading file "/Users/user/.ssh/known_hosts"debug3: record_hostkey: found key type RSA in file /Users/user/.ssh/known_hosts:14debug3: load_hostkeys: loaded 1 keys from [router.example.com]:22debug3: hostkeys_foreach: reading file "/Users/user/.ssh/known_hosts"debug3: record_hostkey: found key type RSA in file /Users/user/.ssh/known_hosts:14debug3: load_hostkeys: loaded 1 keys from [10.1.10.20]:22debug1: Host '[router.example.com]:22' is known and matches the RSA host key.debug1: Found key in /Users/user/.ssh/known_hosts:14debug2: bits set: 3090/6144debug2: set_newkeys: mode 1debug1: SSH2_MSG_NEWKEYS sentdebug1: expecting SSH2_MSG_NEWKEYSdebug2: set_newkeys: mode 0debug1: SSH2_MSG_NEWKEYS receiveddebug1: Roaming not allowed by serverdebug1: SSH2_MSG_SERVICE_REQUEST sentdebug2: service_accept: ssh-userauthdebug1: SSH2_MSG_SERVICE_ACCEPT receiveddebug2: 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,passworddebug3: start over, passed a different list publickey,gssapi-with-mic,passworddebug3: preferred publickey,keyboard-interactive,passworddebug3: authmethod_lookup publickeydebug3: remaining preferred: keyboard-interactive,passworddebug3: authmethod_is_enabled publickeydebug1: Next authentication method: publickeydebug1: Trying private key: /Users/user/.ssh/id_rsadebug3: sign_and_send_pubkey: RSA SHA256:a+3AC5+LSZvVQGRjkcYmIG35SzhOs9kKPv+yy2T6T2odebug2: we sent a publickey packet, wait for replydebug1: 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:5917debug1: channel 0: new [client-session]debug3: ssh_session2_open: channel_new: 0debug2: channel 0: send opendebug1: Entering interactive session.debug1: remote forward success for: listen 5917, connect h3-centos4x32:5917debug1: All remote forwarding requests processeddebug2: callback startdebug2: fd 3 setting TCP_NODELAYdebug3: ssh_packet_set_tos: set IP_TOS 0x10debug2: client_session2_setup: id 0debug2: channel 0: request pty-req confirm 1debug1: Sending environment.debug3: Ignored env SHELLdebug3: Ignored env TERMdebug3: Ignored env TMPDIRdebug3: Ignored env Apple_PubSub_Socket_Renderdebug3: Ignored env EMACSDATAdebug3: Ignored env EMACSPATHdebug3: Ignored env USERdebug3: Ignored env EMACSdebug3: Ignored env SSH_AUTH_SOCKdebug3: Ignored env TERMCAPdebug3: Ignored env __CF_USER_TEXT_ENCODINGdebug3: Ignored env COLUMNSdebug3: Ignored env PATHdebug3: Ignored env PWDdebug3: Ignored env XPC_FLAGSdebug3: Ignored env XPC_SERVICE_NAMEdebug3: Ignored env EMACSLOADPATHdebug3: Ignored env SHLVLdebug3: Ignored env HOMEdebug3: Ignored env LOGNAMEdebug3: Ignored env INFOPATHdebug3: Ignored env DISPLAYdebug3: Ignored env INSIDE_EMACSdebug3: Ignored env EMACSDOCdebug3: Ignored env _debug2: channel 0: request shell confirm 1debug2: callback donedebug2: channel 0: open confirm rwindow 0 rmax 32768debug2: channel_input_status_confirm: type 99 id 0debug2: PTY allocation request accepted on channel 0debug2: channel 0: rcvd adjust 2097152debug2: channel_input_status_confirm: type 99 id 0debug2: 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?– WilliamKFNov 2 '15 at 16:23
  • To be clear, you are trying to forward from the ssh destination side back to your local host yes?– RamFeb 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.– WilliamKFFeb 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?– RamFeb 2 '16 at 16:31
  • @Ram Exactly, I've been doing it for years, then it stopped working once I upgraded to El Capitan.– WilliamKFFeb 2 '16 at 19:00

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?– WilliamKFFeb 3 '16 at 21:09

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

     
    discard

    By posting your answer, you agree to the privacy policy and terms of service.

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