Cinder 可配置 SSH 主机密钥策略¶

包含您的 Launchpad 蓝图的 URL

https://blueprints.launchpad.net/cinder/+spec/configurable-ssh-host-key-policy

为了解决 Cinder 中 SSH 安全性较弱的问题，Cinder 处理 SSH 主机密钥的方式应该可配置，允许系统管理员选择他们希望 SSH 连接的安全性级别。

问题描述¶

在 Icehouse 测试和开发期间，发现 cinder/utils.py 中的 SSHPool 正在使用 paramiko.AutoAddPolicy() 选项。这意味着存储后端上的 SSH 密钥更改将被接受，只会打印一条警告。这留下了一个安全漏洞，因为 Cinder Volume 主机和后端存储之间可能发生中间人 (MITM) 攻击。如果发生 MITM 攻击，用户的数据可能会被泄露。在最坏的情况下，用户可能会被诱骗连接或甚至启动包含恶意代码的欺骗卷。

用例¶

提议的变更¶

该规范和相关的蓝图建议使处理 SSH 主机密钥的方式可配置，允许系统管理员有意识地决定系统上所需的安全级别。

该解决方案需要两个新的配置项以及对当前默认行为的更改。首先，需要一个名为 ‘strict_ssh_host_key_policy’ 的配置选项，其可能设置为 ‘false’（默认值）或 ‘true’。当此选项设置为 ‘false’ 时，它将在首次连接时自动接受主机密钥，然后在主机密钥将来更改时抛出异常。这是默认行为从当前功能变化的地方。

如果 ‘strict_ssh_host_key_policy’ 设置为 ‘true’，则必须配置第二个选项 ‘ssh_host_keys_file’。当使用严格配置时，假定管理员将预先配置 SSH 主机密钥，并且任何与预期密钥的偏差都将通过异常处理。

备选方案¶

显然，我们可以保留当前的功能，但这会留下一个安全漏洞。我们也可以只要求指定一个 ssh 主机密钥文件，但我认为这是不可取的，因为它又是用户必须处理的另一个配置选项。最后一个选项是使功能完全可配置，从而可以保留当前的功能，即主机密钥的更改只会导致报告警告，除了上述新的配置选项外，但我认为如果我们要进行此更改，将安全漏洞保留在原位不是正确的方法。我们实际上是将 Cinder 处理 ssh 密钥的方式与用户从命令行习惯的方式保持一致，这似乎是最明智的方法。

数据模型影响¶

无

REST API 影响¶

无

安全影响¶

此更改通过以一种有助于避免中间人攻击的方式处理 ssh 密钥来提高安全性。

通知影响¶

无

其他最终用户影响¶

如上所述，此更改将使在默认情况下，如果后端存储系统上的 ssh 密钥发生更改，用户将看到连接失败。用户将能够使用 ‘strict_ssh_host_key_policy’ 设置他们希望强制执行的安全性级别，并能够使用 ‘ssh_host_keys_file’ 选项指定他们希望使用的主机密钥。

性能影响¶

无

其他部署者影响¶

希望拥有更安全的 ssh 实现的部署者需要设置 ‘strict_ssh_host_key_policy’ 和 ‘ssh_host_keys_file’ 配置选项。

开发人员影响¶

当前使用 ssh 连接到其后端存储系统的驱动程序需要确保其驱动程序正在使用这种方法来保护其 ssh 密钥。未来的驱动程序开发人员也需要与这种改进的安全模型保持一致。

实现¶

负责人¶

主要负责人: jsbryant (jsbrant@us.ibm.com 或 jungleboyj 在 IRC 上)

工作项¶

对 cinder/utils.py 进行的初始更改以启用此新功能。更新现有驱动程序以正确利用此功能。

依赖项¶

无

测试¶

除了单元测试之外，我认为除非在 Tempest 中有办法模拟返回错误的 ssh 密钥，否则没有更多可以进行的测试。

文档影响¶

需要更新文档以包含配置选项和对功能设计工作方式的解释。

参考资料¶

最初引发此讨论的错误：https://bugs.launchpad.net/cinder/+bug/1320056 社区中 utils.py 的初始修复：https://review.openstack.org/#/c/94165/ 关于此主题的每周 Cinder 会议讨论：http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-05-28-16.00.log.html#l-104

Cinder 可配置 SSH 主机密钥策略