一些 SSH 隧道报告 Linux VM 与 OSX Lion 之间的连接被拒绝

一些 SSH 隧道报告 Linux VM 与 OSX Lion 之间的连接被拒绝

我正在尝试从 Mac OS X Lion 主机连接到在 Centos 6.3 VM 客户机 (VMware Fusion 4) 上运行的一组服务。我在 /var/root 中设置了 .ssh/config 脚本:

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

然后我运行 sudo ssh testbed 来连接隧道。隧道端口 80 需要 Sudo,因此需要 root 权限。

一些隧道工作正常。我可以在 Firefox 中查看 localhost:80、localhost:6800 和 localhost:10081。但是,一些隧道不起作用。它们在浏览器中超时并在 shell 中产生此错误:

channel 19: open failed: connect failed: Connection refused

我最初以为这是端口号造成的,所以对于 5984,我将其隧道传输回 localhost:10080。行为相同(超时 + 错误)。我已使用 shell 中的纯文本浏览器 (lynx) 验证所有服务均正常运行。

我确实想知道这是否是防火墙问题。Guest VM 有防火墙,但它可以顺利打开以进行传出连接。主机操作系统防火墙处于“关闭”状态(系统偏好设置 -> 安全 -> 防火墙)。

netstat 没有显示任何端口冲突

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     

我已经在两种网络配置(NAT 和桥接)中测试了 VM Fusion,并且都表现出相同的行为。

有可能吗:

  1. 主机操作系统上有一个 IPTABLES 防火墙(Mac OS X 中没有 iptables 命令)?
  2. VMware Fusion 中是否存在某种保护措施,可以锁定从客户机到主机的某些端口?
  3. Linux 服务中内置有保护功能,这样一些仅限本地主机的服务就不会被隧道传输?

任何形式的指导都值得赞赏。为了完整起见,以下是使用详细选项的 SSH 事务日志:

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

答案1

是否有一些服务绑定到客户机上的 localhost?如果您从 (host) localhost:8080 到 (guest) 10.xyz:80 执行 ssh 转发,并且该服务正在侦听 (guest) 127.0.0.1:80 ,它将拒绝连接。

尝试从 127.0.0.1:port 到 127.0.0.1:port 建立一个隧道,其中第一个是主机,第二个是客户机。

相关内容