ssh 連接僅從我的 mac 被拒絕，我的 linux 機器連接沒有問題
我有一個奇怪的問題。我有一個 EC2 伺服器（Arch Linux），我可以從我的本地 linux 伺服器毫無問題地訪問（通過 ssh），但是當我嘗試從我的 macbook 連接到我的 EC2 伺服器時，連接被拒絕。
$ ssh -vvv -i key.pem me@myserver.com 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 地址不會發生任何事情。似乎伺服器甚至沒有看到我的嘗試。對於我的 macbook 的嘗試，我在 /var/log/auth.log 中也沒有看到任何輸出，而其他嘗試則被記錄下來。
我在伺服器上創建了一個新密鑰並將私鑰複製回我的 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 似乎確實適用於我可以通過 ssh 訪問的伺服器的 macbook。同樣，我可以毫不費力地從瀏覽器訪問這些框。
好的，我實際上已經解決了這個問題。感謝所有回复的人，尤其是 Eric Hammond。如果我沒有完成跟踪路由，我就不會在Google上搜尋“沒有路由到主機”的問題，也不會想出解決方案。我發現了兩件事，我不確定是哪一個成功了，所以我將兩者都包括在這裡。首先，我發現有些人抱怨 PeerGuardian 應用程序導致了這些問題。我刪除了 PeerGuardian 的應用程序和庫目錄。
提到的另一個解決方案是我下載並執行的 Lion Cache Cleaner。我對所有內容都進行了深度清理，同時確保垃圾被完全清空（在刪除 PeerGuardian 之後）。記憶體清理器執行後，我重新啟動並能夠成功連接到我的伺服器和客戶端的盒子。
再次感謝您的有用建議，如果沒有所有這些幫助，我將無法解決此問題。