尝试login到运行Ubuntu 10.04.1的Amazon EC2实例。 我可以login，很好，没有问题。 来自不同networking的不同用户只需要这样做：
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to xxxx [xxxx] port 80. debug1: Connection established. debug1: identity file /.ssh/identity type -1 debug1: identity file /.ssh/id_rsa type -1 debug1: identity file /.ssh/id_dsa type -1 debug1: loaded 3 keys 然后它挂起。
我们已经尝试在端口22和端口80上运行sshd
我猜测这不是一个防火墙的问题，因为详细的输出报告连接build立。
失败用户连接时，我在/var/log/auth.log中看不到任何内容。 我成功login时看到条目。
这是我定期看到的一个症状，我敢打赌，这是由于您的云服务器和用户networking之间的一个跳跃导致不加区分地过滤掉ICMP消息，导致pathMTU发现失败; 密钥交换是SSH协议的第一部分，很可能是通过套接字发送大的TCP段，并且最有可能触发问题。
两个简单的方法来隔离问题：尝试在同一主机之间进行一些其他协议的大型交换（例如，通过Web表单上载某个文件），或者人为地强制用户主机上的MTU足够小以适应沿networking（〜300b）的任何合理的MTU。 如果问题在其他大型传输过程中popup，并随着MTU的减小而消失，那么您已经find了罪魁祸首。
（发生这种情况的原因是，当发送具有DF（不分段）标志集的IP分组时，不能通过跳跃传输，跳将响应ICMP消息;并且过滤这些ICMP消息是常见的错误configuration由经验不足或偏执的networkingpipe理员 – 所以发送主机永远不知道pathMTU是小于它认为和数据包只是消失在以太）。
坏消息是，这不是一般可以固定在任何端点上的事情，而是在发生不正确过滤的跳跃中。 你可以用手动configuration的MTU来解决这个问题，但这是一个丑陋的黑客攻击，最好是脆弱的。
我们可以通过closuresec2访问控制列表中的ssh端口并查看debugging输出的结果来更明确地消除防火墙吗？ 我怀疑你是对的，但看到不同之处会很有趣。
你有没有其他访问控制在实例方面？ SSH黑名单/白名单？
我知道这是一个非常古老的线索，但没有令人满意地回答（恕我直言）。 我通过谷歌search，其他人也可能。
我通过检查networkingconfiguration解决了这个问题。 我的SSH客户端有一个过时的networking掩码，/ 24而不是/ 22。 我更新了configuration，重新启动了networking，这很好。