我遇到了一个奇怪的问题。我有一台 EC2 服务器 (Arch Linux)，我可以从本地 Linux 服务器访问 (通过 ssh)，没有任何问题，但是当我尝试从我的 macbook ssh 进入我的 EC2 服务器时，我收到连接被拒绝的提示。
$ ssh -vvv -i key.pem [email protected]
OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /etc/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to myserver.com 184.72.xxx.xx port 22.
debug1: connect to address 184.72.xxx.xx port 22: Connection refused
ssh: connect to host myserver.com port 22: Connection refused
我也有工作客户使用 EC2 作为他们的一些服务器，我也遇到了完全相同的问题。我可以从其他机器登录到这些 EC2 机器，但不能从我的 MacBook 登录。我能够从我的 MacBook ssh 到其他服务器，无论是本地还是通过网络。这意味着虽然我的 MacBook 可能存在一些问题，但我仍然能够 ssh 到其他机器。我还能够在我的 MacBook 上访问我从我的服务器提供服务的网站，因此据我所知，该服务器并未被列入我的 MacBook 的黑名单。并非所有 EC2 机器都是这种情况。我在我的 EC2 帐户上使用相同的密钥设置了一个测试实例，并且我能够从我的 MacBook ssh 到该实例。
由于我能够从本地网络上的另一台机器连接到我的 EC2 机器，因此排除了服务器上未运行 ssh、端口可能被阻止以及我的 IP 可能在服务器端被列入黑名单的可能性。如果我在尝试从我的 MacBook 进行 ssh 或 nc 连接时运行 tcpdump，我的本地 IP 地址不会发生任何变化。似乎服务器甚至没有看到我的尝试。我也看不到 /var/log/auth.log 中有关我的 MacBook 尝试的输出，而其他尝试均已记录。
我在服务器上创建了一个新密钥，并将私钥复制回我的 MacBook（在其他地方测试过），但还是无法进入。我检查了 iptables（关闭 iptables 并尝试连接）、/etc/hosts.deny（空）和安全组，其中 ssh（端口 22）完全打开。在我的本地网络上，自从这个问题出现以来，我已经换掉了路由器，但这并没有帮助。这个问题似乎发生在我将 Mac 升级到 Lion 并安装新硬盘时，用户目录保持不变。我不确定问题出在我的 Mac 上，还是 EC2 端，但我现在陷入了困境，因为有两个独立的 EC2 盒子我似乎无法进入（一个 CentOS 和一个 Arch Linux）。
我也尝试过在另一个网络上从我的 MacBook 进行连接；结果相同。我重新编译了 openssh 并将其安装在 /opt/openssh 中，尝试从该位置使用几个不同的密钥运行它，但没有成功。我正在使用 ssh-agent，并尝试删除所有密钥，并明确标识我将要使用的密钥；结果相同。如果这只是一个坏密钥问题，我应该收到一条权限被拒绝的消息，或者如果它尝试使用太多不同的密钥进行连接，则会收到“尝试次数过多”的消息。我直接尝试了 ip 地址，以及 amazon 分配的特殊地址，但这些都不起作用。此外，当我尝试从我的 MacBook ssh 到我的服务器时，它会在详细输出中列出正确的 IP。
以下是对端口 22 进行 telnet 尝试的输出：
telnet mysite.com 22
Trying 184.72.xx.xx...
telnet: connect to address 184.72.xx.xx: Connection refused
telnet: Unable to connect to remote host
基本上，我完全没有主意了，如果能得到任何帮助我都会感激不尽。我觉得我已经尝试了几乎所有的方法，但肯定有些东西是我遗漏的。我的 MacBook 有可能在我不知情的情况下阻止了某些流量吗？我检查了防火墙设置，发现它已被禁用，而且 ipfw 也没有运行（我不这么认为）。
更新：我尝试从我的 MacBook 跟踪路由到我的服务器，但失败了，提示“没有到主机的路由”：
$ traceroute -I 184.72.xx.xx
traceroute to 184.72.xx.xx (184.72.220.0), 64 hops max, 72 byte packets
traceroute: sendto: No route to host
1 traceroute: wrote 184.72.xx.xx 72 chars, ret=-1
*traceroute: sendto: No route to host
traceroute: wrote 184.72.xx.xx 72 chars, ret=-1
*traceroute: sendto: No route to host
traceroute: wrote 184.72.xx.xx 72 chars, ret=-1
*
traceroute: sendto: No route to host
2 traceroute: wrote 184.72.xx.xx 72 chars, ret=-1
*traceroute: sendto: No route to host
traceroute: wrote 184.72.xx.xx 72 chars, ret=-1
*traceroute: sendto: No route to host
traceroute: wrote 184.72.xx.xx 72 chars, ret=-1
从我本地网络上的 Linux 机器来看，一切看起来都很好：
# traceroute -I 184.72.xx.xx
traceroute to 184.72.xx.xx (184.72.xx.xx), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 0.190 ms 0.237 ms 0.282 ms
2 10.1.10.1 (10.1.10.1) 0.946 ms 1.779 ms 2.138 ms
3 76.109.128.1 (76.109.128.1) 16.581 ms 18.187 ms 32.675 ms
4 te-9-2-ur02.delrayeast.fl.pompano.comcast.net (68.85.125.149) 17.810 ms 17.976 ms 18.077 ms
5 te-8-1-ur01.bocaraton.fl.pompano.comcast.net (68.86.165.194) 18.325 ms 18.427 ms 18.521 ms
6 te-3-4-ar01.stuart.fl.pompano.comcast.net (68.86.165.109) 19.430 ms 18.559 ms 18.645 ms
7 te-0-4-0-5-ar03.northdade.fl.pompano.comcast.net (68.85.127.205) 24.839 ms 24.438 ms 24.525 ms
8 pos-0-4-0-0-cr01.miami.fl.ibone.comcast.net (68.86.91.81) 23.113 ms 16.435 ms 24.480 ms
9 xe-10-1-0.edge2.Miami1.Level3.net (64.156.8.9) 23.354 ms 23.544 ms 24.256 ms
10 ae-32-52.ebr2.Miami1.Level3.net (4.69.138.126) 30.777 ms 31.698 ms 31.878 ms
11 ae-2-2.ebr2.Atlanta2.Level3.net (4.69.140.142) 36.471 ms 37.461 ms 37.654 ms
12 ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253) 37.825 ms 37.917 ms 38.013 ms
13 ae-2-2.ebr1.Washington1.Level3.net (4.69.132.86) 50.805 ms 42.708 ms 47.774 ms
14 ae-91-91.csw4.Washington1.Level3.net (4.69.134.142) 48.827 ms 49.018 ms 49.122 ms
15 ae-4-90.edge3.Washington1.Level3.net (4.69.149.209) 56.149 ms 113.159 ms 114.077 ms
16 AMAZON.COM.edge3.Washington1.Level3.net (4.59.144.94) 88.162 ms 47.429 ms 57.533 ms
17 72.21.220.131 (72.21.220.131) 68.472 ms 52.906 ms 57.836 ms
18 72.21.222.143 (72.21.222.143) 58.755 ms 43.988 ms 50.344 ms
19 216.182.224.53 (216.182.224.53) 51.369 ms 43.720 ms 48.007 ms
20 * * *
21 216.182.232.125 (216.182.232.125) 49.900 ms 46.469 ms 50.883 ms
22 * * *
23 * * *
24 mail.myserver.com (184.72.xx.xx) 48.432 ms 45.051 ms 49.796 ms
从服务器返回的结果看起来也很合理：
# traceroute -I 76.109.130.xx
traceroute to 76.109.130.xx (76.109.130.99), 30 hops max, 40 byte packets
1 10.204.200.3 (10.204.200.3) 10.902 ms 4.576 ms 0.466 ms
2 10.1.44.25 (10.1.44.25) 0.621 ms 0.634 ms 0.366 ms
3 10.1.34.136 (10.1.34.136) 0.484 ms 0.804 ms 20.380 ms
4 216.182.232.74 (216.182.232.74) 0.401 ms 0.457 ms 0.415 ms
5 216.182.232.52 (216.182.232.52) 0.373 ms 0.458 ms 0.438 ms
6 72.21.222.156 (72.21.222.156) 1.265 ms 1.280 ms 1.214 ms
7 72.21.220.126 (72.21.220.126) 2.014 ms 2.079 ms 2.089 ms
8 xe-4-0-0.edge3.Washington1.Level3.net (4.59.144.81) 1.369 ms 1.445 ms 1.477 ms
9 vlan90.csw4.Washington1.Level3.net (4.69.149.254) 1.499 ms 1.503 ms 1.498 ms
10 ae-91-91.ebr1.Washington1.Level3.net (4.69.134.141) 2.367 ms 2.272 ms 2.453 ms
11 ae-2-2.ebr3.Atlanta2.Level3.net (4.69.132.85) 15.431 ms 15.273 ms 15.684 ms
12 ae-73-73.ebr2.Atlanta2.Level3.net (4.69.148.254) 18.637 ms 21.841 ms 26.061 ms
13 ae-2-2.ebr2.Miami1.Level3.net (4.69.140.141) 29.121 ms 32.777 ms 36.370 ms
14 ae-2-52.edge2.Miami1.Level3.net (4.69.138.102) 28.909 ms 28.445 ms 28.545 ms
15 4.59.85.46 (4.59.85.46) 29.504 ms 29.760 ms 29.013 ms
16 pos-0-13-0-0-ar03.northdade.fl.pompano.comcast.net (68.86.90.230) 30.111 ms 31.494 ms 32.045 ms
17 te-8-7-ar01.stuart.fl.pompano.comcast.net (68.85.127.194) 33.002 ms 32.879 ms 33.023 ms
18 te-9-1-ur01.bocaraton.fl.pompano.comcast.net (68.86.165.110) 35.068 ms 34.887 ms 34.901 ms
19 te-9-4-ur02.delrayeast.fl.pompano.comcast.net (68.86.165.193) 36.183 ms 35.679 ms 35.730 ms
20 te-17-10-cdn04.delrayeast.fl.pompano.comcast.net (68.85.125.146) 48.517 ms 56.562 ms 55.199 ms
21 c-76-109-130-xx.hsd1.fl.comcast.net (76.109.130.xx) 43.331 ms 49.565 ms 45.136 ms
我还针对另一个我无法连接的 EC2 盒子测试了 traceroute，结果相同。Traceroute 似乎在我的 MacBook 上对我可以通过 ssh 访问的服务器有效。同样，我可以通过浏览器毫无困难地访问这些盒子。
答案1
好的，我实际上已经解决了这个问题。感谢所有回复的人，特别是 Eric Hammond。如果我没有进行跟踪路由，我就不会在 Google 上搜索“无路由到主机”问题，也不会找到解决方案。我发现了两件事，我不确定是哪一件事起了作用，所以我将两者都包括在这里。首先，我发现有些人抱怨 PeerGuardian 应用程序导致了这类问题。我删除了该应用程序和 PeerGuardian 的库目录。
解决方案中提到的另一个东西是 Lion Cache Cleaner，我下载并运行了它。我对所有内容进行了深度清理，并确保垃圾已完全清空（删除 PeerGuardian 后）。缓存清理程序运行后，我重新启动并能够成功连接到我的服务器和客户端的盒子。
再次感谢您的帮助建议，如果没有这些帮助，我就无法解决这个问题。
答案2
虽然可能性不大，但是您是否尝试过从 Mac 上的已知主机文件中删除 myserver.com 条目？（我相信是 ~/.ssh/known_hosts）