![一组工作站拒绝通过 SSH 连接其他工作站,但可以顺利地与其他工作站建立连接](https://linux22.com/image/639338/%E4%B8%80%E7%BB%84%E5%B7%A5%E4%BD%9C%E7%AB%99%E6%8B%92%E7%BB%9D%E9%80%9A%E8%BF%87%20SSH%20%E8%BF%9E%E6%8E%A5%E5%85%B6%E4%BB%96%E5%B7%A5%E4%BD%9C%E7%AB%99%EF%BC%8C%E4%BD%86%E5%8F%AF%E4%BB%A5%E9%A1%BA%E5%88%A9%E5%9C%B0%E4%B8%8E%E5%85%B6%E4%BB%96%E5%B7%A5%E4%BD%9C%E7%AB%99%E5%BB%BA%E7%AB%8B%E8%BF%9E%E6%8E%A5.png)
我有一组 Ubuntu 14.04 工作站,它们都是通过映像部署的克隆。映像完成后,它们被分配了一个静态 IP,并且它们还删除/重新生成了主机密钥。它们各自看起来都很好,它们可以很好地连接到文件服务器、计算集群等,但它们无法通过 SSH 相互连接,并且一直挂起(直到它们在约 10 分钟后超时)debug1: SSH2_MSG_KEXINIT sent
。
我可以通过 Windows 笔记本电脑、较旧的 12.04 工作站或 12.04 服务器顺利地连接到它们,或者通过任何其他方式从一个有问题的工作站连接到另一个有问题的工作站,但不能互相连接。
答案1
我可以通过在网络连接中引入 PMTU 黑洞来重现该症状。
在 Ubuntu 12.04 上,密钥交换初始化消息大小约为 1KB,完全在典型网络 MTU 范围内。在 Ubuntu 14.04 上,密钥交换初始化消息大小已增长到近 2KB,使其成为连接期间第一条超过典型网络 MTU 的消息。
这意味着 MTU 问题的症状将发生变化。以前您可能能够连接,但通过连接传输大型文件或运行快速产生大量输出的命令可能会导致连接停滞。但现在 MTU 问题会导致连接在身份验证之前停滞。
在确定根本原因之前,减少网络接口上的 MTU 是一种可用的解决方法。它还可用于确认问题确实与 MTU 有关。如果网络接口称为eth0
,您可以尝试以下命令:
ifconfig eth0 mtu 1280