Estou tentando conectar-me a um conjunto de serviços executados em um convidado VM Centos 6.3 (VMware Fusion 4) de um host Mac OS X Lion. Eu configurei o script .ssh / config em / var / root:
Host testbed
Hostname testbed
User <username>
Port 15922
# web server
LocalForward localhost:80 testbed:80
# zend server admin console
LocalForward localhost:10081 testbed:10081
# zend debugger
LocalForward localhost:10000 testbed:10000
# mongodb
LocalForward localhost:28017 testbed:28017
# couchdb
LocalForward localhost:10080 testbed:5984
# scrapyd
LocalForward localhost:6800 testbed:6800
# eclipse connection for zend debugger
RemoteForward testbed:10137 localhost:10137
Eu então executo o sudo ssh testbed para conectar os túneis. Sudo é necessário para a porta do túnel 80, portanto, raiz.
Alguns dos túneis funcionam bem. Eu posso ver localhost: 80, localhost: 6800 e localhost: 10081 no Firefox. No entanto, alguns dos túneis não funcionam. Eles esgotam o tempo no navegador e produzem esse erro no shell:
channel 19: open failed: connect failed: Connection refused
Eu pensei inicialmente que este era um artefato do número da porta, então para 5984, eu o canalizei de volta para o localhost: 10080. O comportamento foi o mesmo (tempo limite + erro). Verifiquei que todos os serviços estão sendo executados corretamente usando um navegador somente texto (lynx) no shell.
Eu me perguntei se isso era um problema de firewall. A VM Guest tem um firewall, mas é aberta para conexões de saída. O firewall do sistema operacional host está "Desativado" (Preferências do sistema - > Segurança - > Firewall).
netstat não mostra colisões nas portas
tcp6 0 0 ::1.6800 *.* LISTEN
tcp4 0 0 127.0.0.1.6800 *.* LISTEN
tcp6 0 0 ::1.10080 *.* LISTEN
tcp4 0 0 127.0.0.1.10080 *.* LISTEN
tcp6 0 0 ::1.28017 *.* LISTEN
tcp4 0 0 127.0.0.1.28017 *.* LISTEN
tcp6 0 0 ::1.10000 *.* LISTEN
tcp4 0 0 127.0.0.1.10000 *.* LISTEN
tcp6 0 0 ::1.10081 *.* LISTEN
tcp4 0 0 127.0.0.1.10081 *.* LISTEN
tcp6 0 0 ::1.80 *.* LISTEN
tcp4 0 0 127.0.0.1.80 *.* LISTEN
Eu testei o VM Fusion em duas configurações de rede (NAT e Bridged) e ambas exibem o mesmo comportamento.
É possível que:
Qualquer tipo de orientação é apreciada. Para completar, aqui está um log da transação SSH usando a opção detalhada:
OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /var/root/.ssh/config
debug1: Applying options for testbed
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug1: Connecting to testbed [XX.XX.XX.XXX] port 15922.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /var/root/.ssh/id_rsa type -1
debug1: identity file /var/root/.ssh/id_rsa-cert type -1
debug1: identity file /var/root/.ssh/id_dsa type -1
debug1: identity file /var/root/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '[testbed]:15922' is known and matches the RSA host key.
debug1: Found key in /var/root/.ssh/known_hosts:7
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering DSA public key: /path/to/my/private-key.ppk
debug1: Server accepts key: pkalg ssh-dss blen 817
debug1: Authentication succeeded (publickey).
Authenticated to testbed ([10.12.1.154]:15922).
debug1: Local connections to localhost:80 forwarded to remote address testbed:80
debug1: Local forwarding listening on 127.0.0.1 port 80.
debug1: channel 0: new [port listener]
debug1: Local forwarding listening on ::1 port 80.
debug1: channel 1: new [port listener]
debug1: Local connections to localhost:10081 forwarded to remote address testbed:10081
debug1: Local forwarding listening on 127.0.0.1 port 10081.
debug1: channel 2: new [port listener]
debug1: Local forwarding listening on ::1 port 10081.
debug1: channel 3: new [port listener]
debug1: Local connections to localhost:10000 forwarded to remote address testbed:10000
debug1: Local forwarding listening on 127.0.0.1 port 10000.
debug1: channel 4: new [port listener]
debug1: Local forwarding listening on ::1 port 10000.
debug1: channel 5: new [port listener]
debug1: Local connections to localhost:28017 forwarded to remote address testbed:28017
debug1: Local forwarding listening on 127.0.0.1 port 28017.
debug1: channel 6: new [port listener]
debug1: Local forwarding listening on ::1 port 28017.
debug1: channel 7: new [port listener]
debug1: Local connections to localhost:10080 forwarded to remote address testbed:5984
debug1: Local forwarding listening on 127.0.0.1 port 10080.
debug1: channel 8: new [port listener]
debug1: Local forwarding listening on ::1 port 10080.
debug1: channel 9: new [port listener]
debug1: Local connections to localhost:6800 forwarded to remote address testbed:6800
debug1: Local forwarding listening on 127.0.0.1 port 6800.
debug1: channel 10: new [port listener]
debug1: Local forwarding listening on ::1 port 6800.
debug1: channel 11: new [port listener]
debug1: Remote connections from testbed:10137 forwarded to local address localhost:10137
debug1: channel 12: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: remote forward success for: listen 10137, connect localhost:10137
debug1: All remote forwarding requests processed
debug1: Sending environment.
debug1: Sending env LANG = en_GB.UTF-8
Last login: Mon Sep 3 12:27:10 2012 from something.somenet
[me@testbed ~]$ debug1: Connection to port 10080 forwarding to testbed port 5984 requested.
debug1: channel 13: new [direct-tcpip]
channel 13: open failed: connect failed: Connection refused
debug1: channel 13: free: direct-tcpip: listening port 10080 for testbed port 5984, connect from 127.0.0.1 port 54639, nchannels 14
debug1: Connection to port 10080 forwarding to testbed port 5984 requested.
debug1: channel 13: new [direct-tcpip]
channel 13: open failed: connect failed: Connection refused
debug1: channel 13: free: direct-tcpip: listening port 10080 for testbed port 5984, connect from 127.0.0.1 port 54640, nchannels 14
Alguns dos serviços estão vinculados ao host local no convidado? Se você fizer um ssh forward de host (host) local: 8080 para (guest) 10.x.y.z: 80 e o serviço estiver escutando em (guest) 127.0.0.1:80, ele fará com que a conexão seja recusada.
Tente criar um túnel de 127.0.0.1:port para 127.0.0.1:port, onde o primeiro é host e o segundo é guest.