修复 CentOS 9 安装 panopta-agent GPG/SHA1 校验失败问题
2025-04-22 02:49:37
搞定 CentOS 9 安装 panopta-agent 时的 GPG 签名校验失败问题
刚上手 CentOS 9，准备用 dnf install panopta-agent 装个 Panopta 监控代理，结果 DNF 报了个错，安装失败。报错信息挺明确，卡在了 GPG 校验这一步。
# dnf install panopta-agent
... (仓库信息同步输出省略) ...
Dependencies resolved.
============================================================================================================================================================================================================
Package Architecture Version Repository Size
============================================================================================================================================================================================================
Installing:
panopta-agent x86_64 2022.47.1-0.1 panopta.repo 8.4 M
Installing dependencies:
libuv x86_64 1:1.42.0-2.el9 appstream 148 k
pcp-conf x86_64 6.3.2-3.el9 appstream 32 k
pcp-libs x86_64 6.3.2-3.el9 appstream 647 k
sysstat x86_64 12.5.4-9.el9 appstream 482 k
Transaction Summary
============================================================================================================================================================================================================
Install 5 Packages
Total download size: 9.7 M
Installed size: 30 M
Is this ok [y/N]: y
Downloading Packages:
... (包下载进度省略) ...
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total 9.2 MB/s | 9.7 MB 00:01
warning: Signature not supported. Hash algorithm SHA1 not available. # <--- 注意看这里！
warning: Signature not supported. Hash algorithm SHA1 not available. # <--- 还有这里！
Problem opening package panopta-agent-2022.47.1-0.1.x86_64.rpm
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: GPG check FAILED # <--- 最终的报错
得，关键信息是 warning: Signature not supported. Hash algorithm SHA1 not available. 和 Error: GPG check FAILED。看来是 GPG 签名惹的祸。
为什么会这样？
简单来说，GPG 签名就像是软件包的“数字身份证”加“封条”。仓库维护者用私钥给软件包签名，你用对应的公钥来验证。这能保证两件事：
- 软件包来源可信 ：确认这个包确实是官方或者你信任的源发布的，没被中间人掉包。
- 软件包未被篡改 ：保证你下载到的文件内容和发布时一模一样，没被黑客塞点私货。
dnf（以及之前的 yum）在安装软件包时，默认会执行这个 GPG 校验步骤。如果校验失败，出于安全考虑，dnf 就不会继续安装。
那这次失败的原因是什么呢？注意看那个警告信息：Hash algorithm SHA1 not available。
这意思是，panopta-agent 这个软件包的 GPG 签名使用了 SHA1 哈希算法。而 CentOS 9（以及 RHEL 9 和其他衍生版）出于安全考虑，收紧了默认的系统级加密策略 (Crypto Policies) 。在默认的 DEFAULT 策略下，SHA1 这种被认为不够安全的哈希算法签名，默认是不被支持和信任的。
相当于安检升级了，老款式的“身份证 + 封条”（SHA1 签名）过不了新的安检标准，于是就被拦下来了。
解决办法来了
知道了原因，就好对症下药了。有几种方法可以绕过或者解决这个问题，效果和风险各不相同。
方法一：临时放宽加密策略 (临时抱佛脚)
这是直接针对“安检标准太严”这个问题的解决办法。我们可以暂时把系统的加密策略调低到 LEGACY（遗留）级别，这个级别允许使用 SHA1 签名。
原理和作用:
系统加密策略 (crypto-policies) 统一管理着核心加密组件（如 TLS、IPsec、DNSSec、Kerberos 和 GPG）的设置。通过切换策略级别，可以全局性地调整允许使用的加密算法和协议。LEGACY 策略包含了 DEFAULT 的所有功能，并额外启用了一些较旧、可能不够安全的算法（比如 SHA1）。
操作步骤:
-
切换到 LEGACY 策略:
打开终端，执行以下命令：sudo update-crypto-policies --set LEGACY系统会提示你策略已更新。
-
重新安装 Panopta Agent:
现在再尝试安装panopta-agent：sudo dnf install panopta-agent这次 GPG 校验应该就能通过了（因为它现在接受 SHA1 签名了）。
-
切回 DEFAULT 策略 (重要!):
安装成功后，强烈建议 把加密策略恢复到默认设置，以保持系统的安全性：sudo update-crypto-policies --set DEFAULT
安全建议:
LEGACY 策略会降低整个系统的安全基线，因为它允许了一些已知不够安全的加密算法。这可能会影响到其他依赖系统加密库的应用（比如 SSH、HTTPS 连接等）。所以，切记在完成 panopta-agent 安装后，立刻切回 DEFAULT 策略！ 不要让系统一直运行在 LEGACY 模式下。
方法二：安装时忽略 GPG 校验 (险招，慎用!)
这种方法更直接，就是告诉 dnf，这次安装你别管什么 GPG 签名了，直接装！
原理和作用:
dnf 提供了一个命令行选项 --nogpgcheck，让它在当前这次事务中跳过所有软件包的 GPG 签名校验步骤。
命令行指令:
sudo dnf install panopta-agent --nogpgcheck
执行这个命令，dnf 会下载软件包，然后直接进行安装，不再检查 GPG 签名是否有效。
安全建议:
这是最不推荐的方法！ 跳过 GPG 校验意味着你放弃了验证软件包来源和完整性的机制。如果你下载的 RPM 包在传输过程中被篡改了，或者你连接的仓库本身就有问题，dnf 也发现不了。只有在你完全信任你的网络环境和软件包来源，并且愿意承担潜在风险的情况下，才考虑用这招。用之前最好能手动校验一下下载的 RPM 包（比如通过官方提供的 SHA256/MD5 哈希值），但这往往也不容易做到。
相当于快递来了，你不看发件人信息，也不检查包裹有没有被拆过，直接就签收了。风险自负。
方法三：修改仓库配置，禁用 GPG 校验 (不推荐)
这个方法是针对特定仓库永久禁用 GPG 校验。效果类似方法二，但影响范围是整个 panopta.repo 仓库，而不是单次安装。
原理和作用:
DNF 的仓库配置文件（通常在 /etc/yum.repos.d/ 目录下）里，有一个 gpgcheck 参数。设置为 1 表示启用 GPG 校验，设置为 0 表示禁用。我们可以修改 Panopta 仓库的配置文件来禁用校验。
操作步骤:
-
找到 Panopta 仓库配置文件:
一般文件名是/etc/yum.repos.d/panopta.repo（具体文件名可能根据你添加仓库的方式略有不同）。你可以用ls /etc/yum.repos.d/查看一下。 -
编辑配置文件:
使用你喜欢的文本编辑器（如vim或nano）打开这个文件，需要sudo权限：sudo vim /etc/yum.repos.d/panopta.repo -
修改
gpgcheck参数:
在文件里找到[panopta.repo]或类似段落，找到gpgcheck=1这一行，把它改成gpgcheck=0。如果没找到gpgcheck这一行，你可以在对应的仓库段落下手动添加一行gpgcheck=0。修改前可能是这样：
[panopta.repo] name=Panopta Repository baseurl=... enabled=1 gpgcheck=1 # <-- 把这里的 1 改成 0 gpgkey=...修改后：
[panopta.repo] name=Panopta Repository baseurl=... enabled=1 gpgcheck=0 # <-- 改成 0 gpgkey=...保存并关闭文件。
-
清除 DNF 缓存 (可选但推荐):
为了确保 DNF 读取到最新的配置，可以清理一下缓存：sudo dnf clean all -
安装 Panopta Agent:
现在再执行安装命令，DNF 就不会对来自panopta.repo仓库的包进行 GPG 校验了：sudo dnf install panopta-agent
安全建议:
和方法二类似，这也会带来安全风险，因为你永久性地信任了来自这个仓库的所有包，不再检查它们的签名。这样做比单次使用 --nogpgcheck 更危险，因为它会影响后续该仓库的所有安装和更新。除非你确认风险可控，否则非常不建议 这样做。如果非要用，最好在安装完成后，再把 gpgcheck 改回 1。
方法四：联系 Panopta/Fortinet 更新签名 (长久之计)
以上三种方法都是本地的“权宜之计”，治标不治本。最根本、最安全的解决办法，是让 Panopta (现在是 Fortinet 的一部分) 更新他们软件包的签名，使用更安全的哈希算法（如 SHA256 或 SHA512）。
原理和作用:
软件提供商应该跟上操作系统和安全标准的发展。RHEL 9 / CentOS 9 默认禁用 SHA1 签名是既定事实，提供商需要更新他们的构建和签名流程来兼容。
操作步骤:
- 访问 Panopta/Fortinet 支持渠道: 查找他们的官方文档、社区论坛或客户支持联系方式。
- 报告问题: 清晰地你在 CentOS 9 上遇到的
GPG check FAILED和SHA1 not available的问题。提供你的操作系统版本 (cat /etc/os-release) 和详细的错误日志。 - 请求更新: 建议他们更新 RPM 包的 GPG 签名，使用 SHA256 或更强的哈希算法，以符合 RHEL 9 / CentOS 9 的默认加密策略。
优点:
这是最“正确”的解决方案。一旦官方更新了签名，你就可以像安装其他正常软件包一样，直接使用 dnf install panopta-agent，无需任何特殊操作或安全妥协。同时，这也帮助了其他遇到同样问题的用户。
缺点:
这需要时间，取决于供应商的响应速度和开发周期。短期内你可能还是需要用方法一、二、三来应急。
进阶：理解加密策略
CentOS 9 (以及 RHEL 9+) 引入的系统级加密策略是个挺有用的东西。它提供了一种集中管理系统范围内加密配置的方式。主要有几个预设级别：
- LEGACY: 兼容性最好，但安全性最低。允许一些旧的、弱的算法和协议（比如 SHA1 签名，TLS 1.0/1.1）。
- DEFAULT: 默认级别，在安全性和兼容性之间做了较好的平衡。禁用了一些已知的弱算法（比如 SHA1 签名）。这是 CentOS 9 Stream 的默认设置。
- FUTURE: 面向未来的策略，只允许非常强的加密算法和协议。可能会导致与一些旧系统或服务不兼容。
- FIPS: 符合美国联邦信息处理标准 (FIPS 140-2) 的模式。
你可以用这个命令查看当前生效的策略：
update-crypto-policies --show
理解这个机制，有助于你判断遇到类似加密相关问题时，是不是和系统策略有关，以及调整策略可能带来的影响。
总的来说，遇到 GPG check FAILED 并且提示 SHA1 not available 时，优先考虑是不是可以临时调整加密策略 (方法一)，或者督促软件提供商更新签名 (方法四)。尽量避免直接忽略 GPG 校验 (方法二、三)，那始终是个安全隐患。
