Como obter o tunelamento SSH para funcionar no Macintosh OSX El Capitan?

1

Eu fiz o upgrade de Yosemite para El Capitan, mas agora o SSH tunneling parece estar quebrado. Antes da atualização, eu poderia tunelar minha sessão VNC de outro computador usando o aplicativo SSH Tunnel Manager , mas após a atualização, agora ele entra em uma reconexão de loop. Eu também tentei um comando manual de um shell:

ssh -p 22 -R 5917:host-centos5x32:5917 [email protected]

O ssh se conecta, mas o Real VNC v5.0.4 não exibe o visor VNC 17 com o erro em uma caixa de diálogo (somente a opção é OK):

VNC Viewer
connect: Connection refused (61)

Ambas as formas de tunelamento funcionaram bem em Yosemite, mas agora sempre falha com El Capitan.

Aqui está a verbosidade de nível 3 do ssh:

bash-3.2$ ssh -vvv -p 22 -R 5917:h3-centos4x32:5917 [email protected]
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: [email protected],[email protected],ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: [email protected],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: [email protected],[email protected],ssh-rsa,[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-dss
debug2: kex_parse_kexinit: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1,[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1,[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],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,[email protected]
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,[email protected]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: none,[email protected]
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 que eu posso conectar meu VNC dentro de um Windows 10 rodando com o Oracle VirtualBox VM no meu Macintosh OSX El Capitan como um trabalho e tunelamento com putty. Eu também tentei uma implementação alternativa do ssh no Macintosh e teve o mesmo problema.

Atualização: Agora, o Mac apresenta o seguinte aviso, enquanto a VM do Windows dentro do Mac continua a ssh e o túnel corretamente:

Warning: remote port forwarding failed for listen port 5917

    
por WilliamKF 26.10.2015 / 22:25

2 respostas

2
Primeiro, resumirei seu caso de uso como entendi: Você deseja ssh para um dispositivo de borda (router.example.com) e configurar a regra de encaminhamento por meio do túnel SSH que permite a VNC do seu cliente (o host você está iniciando o ssh de) para host-centos5x32: 5917 onde você tem um servidor VNC escutando.

O que você configurou é uma regra que encaminhará do servidor ssh (router.example.com) para o host de destino (host-centos5x32).

Eu usaria este comando ssh em vez disso: ssh -L 5917: host-centos5x32: 5917 [email protected]

Larguei -p 22, já que é o padrão e alterei sua regra -R (escute no destino e encaminhe como especificado) para uma regra -L (ouça no meu host local e encaminhe conforme especificado). Quando isso estiver ativo, você poderá vnc para localhost: 5917 (ou localhost display 18) e será roteado como esperado. Pode ser mais simples diagnosticar isso usando 'telnet localhost: 5917' ou 'nc localhost 5917', o VNC responderá com algo como "RFB 003.008".

    
por 03.02.2016 / 20:58
0

Não tenho certeza se você ainda está tendo um problema ou não tem uma solução para o seu Mac, mas depois de descobrir o mesmo problema descobri que consegui usar o RealVNC e vincular minha porta de host local em uma sessão de terminal o porto de destino.

ssh -L 5902:localhost:5901 hostname

A sintaxe do argumento é [bind_address:]port:host:hostport .

Em seguida, direcione sua sessão VNC localhost:2 .

    
por 06.01.2016 / 21:42