☰

为什么 ssh 在“debug1：已加载 3 个密钥”后挂起

tag-icon • tag-icon ssh
为什么 ssh 在“debug1：已加载 3 个密钥”后挂起

尝试登录运行 Ubuntu 10.04.1 的 Amazon EC2 实例。我可以正常登录，没有任何问题。来自不同网络的其他用户只会收到此信息：

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

我猜测这不是防火墙问题，因为详细输出报告连接已建立。

当失败的用户连接时，我在 /var/log/auth.log 中看不到任何内容。当我成功登录时，我确实看到了条目。

答案1

这是我定期看到的症状，我敢打赌，这是由于您的云服务器和用户网络之间的某一跳不加区分地过滤掉 ICMP 消息，导致路径 MTU 发现失败；密钥交换是 SSH 协议的第一部分，其中可能通过套接字发送大型 TCP 段，并且最有可能触发问题。

隔离问题的两种简单方法：尝试通过其他协议在相同主机之间进行大型交换（例如，通过 Web 表单上传某个文件），或者人为地将用户主机上的 MTU 强制为某个足够小的值，以适应网络上任何合理的 MTU（~300b）。如果问题在其他大型传输过程中出现，并在较小的 MTU 下消失，那么您就找到了罪魁祸首。

（发生这种情况的原因是，当传输设置了 DF（不分段）标志的 IP 数据包时，如果该数据包无法通过跳跃，则跳跃将使用 ICMP 消息进行响应；而过滤掉这些 ICMP 消息是缺乏经验或过于偏执的网络管理员常见的错误配置 - 因此发送主机永远不会知道路径 MTU 比它想象的要小，数据包就会消失在以太中）。

坏消息是，这个问题通常不能在任一端点解决，只能在发生不当过滤的跳转点解决。您可以通过手动配置 MTU 来解决这个问题，但这是一种丑陋的黑客行为，而且充其量也非常脆弱。

答案2

我们可以通过关闭 ec2 访问控制列表中的 ssh 端口并查看调试输出的样子来更彻底地消除防火墙吗？我想你是对的，但看看其中的区别会很有趣。

实例端还有其他访问控制吗？SSH 黑名单/白名单？

答案3

我知道这是一个非常老的话题，但答案并不令人满意（恕我直言）。我是通过谷歌搜索找到这里的，其他人可能也会找到。

我通过检查网络配置解决了这个问题。我的 SSH 客户端有一个过时的网络掩码，/24 而不是 /22。我更新了配置，重新启动了网络，一切正常。

相关内容