我得到了检查各种服务器配置的自动 PCI 安全测试结果。由于在 ssh 配置的某些元素中使用了 sha1 算法，自动化测试确定服务器不安全。
运行 ssh -vvv 时可以看到配置，因此这里是该输出的相关部分。我剪掉了这个特定服务器上可用的其他算法，但有几个可用。
debug2: KEX algorithms: ...snip...diffie-hellman-group14-sha1
debug2: MACs ctos: hmac-sha1...snip...
它的用途是：
我已经对该站点进行了一些搜索，但没有看到太多关于这些算法是否 1) 正在使用 2) 被认为对于 2019 年符合 PCI 的站点不安全的数据。
经验法则：SHA1在用于相对静态的数据时可能不安全，例如代码签名、数字签名、文件哈希。
PCI FAQ 反映了这一点：
当一个散列函数被迭代应用时（例如 HMAC、PBKDF2），它受冲突的影响比它们的底层散列函数本身要小得多。参考。HMAC（维基百科）。从安全角度来看（2019 年），HMAC-SHA1（和 HMAC-MD5）仍然是安全的。
同样，Diffie-Hellman 的动态特性意味着它的弱点在于控制其素数的位数，而不是它使用的散列函数。详细说明 ConsideredHarmful 指出的内容：diffie-hellman-group14-sha1 是安全的，因为它使用 2048 位素数，而 diffie-hellman-group1-sha1 不是因为它仅使用 1024 位。
这些发现都不是关键的，它们只是最佳实践。没有比蛮力更好的对 SHA1 的实际一般攻击（在撰写本文时）。Natanael在上面的线程中正确指出 SHA1 冲突不会中断hmac-sha1。
diffie-hellman-group14-sha1PCI 仍然可以接受，因为它是一个 2048 位组：https : //weakdh.org/sysadmin.html。
这相当于一个 ~112 位对称密钥（3DES 的有效安全性），在 2023 年之前 NIST 认为这是可以接受的（参见NIST SP800-131A rev 2 的第 128 页表 1 ）。
对于 AES 密钥交换，如果您希望保持 >= 128 位的安全性，您可能应该使用 >= 3200 位的 DH 组（请参阅RFC-3526）。满足此要求的最小组是diffie-hellman-group16-sha512（参见RFC-5656）。
如果您可以安全地立即放弃对非椭圆曲线密钥交换和基于 SHA1 的 HMAC 的支持，那么就这样做。否则，请立即开始计划，因为加密迁移项目是一个巨大的痛苦，您最终可能需要这样做。
请注意，某些 FIPS 要求要求使用hmac-sha1.