SSH到IP而不是完全限定的主机名:这是否降低MITM的风险？

Question

我正在将配置管理应用于由VPS托管公司托管的VPS。不幸的是，改变托管公司不是一种选择。

此VPS具有以下属性：

1. 当新成像或重成像时，它生成一个新的、随机的、SSH公钥/私钥对；
2. 无论是VPS主机托管公司的网络接口，还是VPS托管公司的API，都没有提供一种方法来替换该密钥对为已知的密钥对；
3. 无论是VPS托管公司的网络接口，还是VPS托管公司的API，都没有提供获取密钥对公钥指纹的方法；
4. VPS主机没有签署(例如DNSSEC) DNS记录；
5. VPS托管公司的网络接口和API确实允许检索VPS的IP地址；
6. VPS托管公司的网络接口和API确实使用TLS，并且拥有来自一个体面CA的有效证书；
7. VPS托管公司的网络接口确实允许上传SSH客户端的公钥，之后每次重新映射VPS之后，它都会将该公钥添加到指定帐户的.ssh/authorized_keys文件中。

上面的第一点通常是一件好事，但再加上接下来的两点，这意味着配置管理工具不可能在VPS被重新映像之后第一次通过SSH登录到VPS，以确定连接是否是中间人。换句话说，配置管理工具最多只能使用信任优先使用(“豆腐”)方法。

通常，我会在配置管理工具中使用VPS的完全限定主机名作为VPS的标识符，并且通过单独获取VPS的SSH公钥指纹(例如通过安全API)来避免豆腐的需要。但是，对于这个特定的VPS，后一步是不可能的。

因此，通过完全限定的主机名进行连接似乎有可能受到MITM攻击，例如通过DNS欺骗，利用配置管理工具必须使用豆腐这一事实。

在我看来，这里最安全的选择是从HTTPS上的API中获取VPS的IP地址，并将配置管理工具SSH改为SSH。至少这样可以避免DNS欺骗风险。

(此外，利用上面第7点的优势意味着，即使恶意服务器成功地伪装成VPS，至少恶意服务器也不会获得客户端的密码或私钥。)

我说对了吗？还有其他的风险，或更好的解决方案，我忽略了吗？

Answer 1

一般来说，使用VPS公司的API是个好主意，因为它具有适当的可靠性，并且有足够的资源来实现和维护您的API。毕竟，SSH密钥管理功能迟早会添加到所述API中(甚至在您的特性请求时，谁知道呢？)

然而，简单地说，DNS缓存中毒是一种罕见而复杂的攻击。在您的特定情况下，还有一个相当短的攻击窗口(在创建和分配一个FQDN和第一次尝试登录之间)，这需要攻击者提供完美的时间或内部知识(或两者兼而有之)。此外，在大多数情况下，虚拟服务器分配的FQDN相当随机和模糊，攻击者也必须猜到这一点。

接下来，VPS公司的DNS服务器很可能从本地配置文件或某种数据库中检索VPS的FQDN。假设是这样；如果您的ISP和所有在您的解析器和VPS公司网络之间的传输ISP没有进行任何邪恶的MitM攻击；如果您能够直接使用VPS公司的DNS服务器来解决新创建的VPS的FQDN；那么理论上可以在您的解析器上应用DNS缓存中毒的网络中唯一的位置。因此，鉴于当前DNS中毒攻击的性质，您可以很容易地检测和适当地减轻DNS中毒的尝试。

另外，如果您的威胁模型包括此类攻击，请注意因特网路由并不比DNS更安全。因此，最好在分配所有后续虚拟服务器的同一位置设置一个专用VPS，这样新创建的VPS的第一次使用将来自同一网络段中的计算机，从而消除了劫持分配的IP地址的可能性。

虽然ARP欺骗在很大程度上依赖于各自的虚拟网络体系结构，但它也可能以大致相同的方式造成危害。

尽管如此，正如我已经指出的那样，这些攻击对于一个普通的面向互联网的服务来说是相当假设的。您的里程可能会有所不同；但是，我最好集中精力进行适当的监视和报告，以确保在发生类似情况时，您会尽快知道这一点。