Yum软件包签名验证怎么操作

在Linux系统管理和运维中，软件包的签名验证是保证系统安全的重要一环。今天，我们就来聊聊Yum软件包管理器的签名验证应该怎么操作。这部分内容其实并不复杂，但确实有几个关键点需要注意，尤其是当你在管理多台服务器、使用第三方仓库时。

启用与配置签名验证

Yum的签名验证机制，本质上是让系统在安装或更新软件包之前，先检查一下这个包是否来自可信的发布方，是否被篡改过。这就像快递员送包裹前先核对一下寄件人的身份和包裹的封条。

全局层面，需要在 /etc/yum.conf 中设置 gpgcheck=1。这样一来，所有仓库的安装和更新操作都会自动触发签名校验。

[main]
gpgcheck=1

更精细的配置在仓库层面。每个 /etc/yum.repos.d/*.repo 文件里的仓库段，都需要独立设置 gpgcheck=1，并通过 gpgkey 指定公钥的位置。这个公钥可以是本地文件路径，也可以是远程URL。

[base]
name=CentOS-$releasever - Base
baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

值得一提的是，部分第三方仓库还提供了 repo_gpgcheck=1 选项，用于验证仓库元数据本身的签名。如果对安全性要求较高，可以按需开启。以上配置都是Yum的标准做法，默认情况下系统就会进行签名校验。

导入GPG公钥

光配置好了签名校验还不行，你得先把对应的公钥导入到系统里。公钥就像是“钥匙”，Yum用它来解包签名、验证身份。

导入系统发行版的密钥很简单。比如RHEL/CentOS 7：

sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

Fedora用户则根据版本选择对应的密钥文件：

sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-

第三方仓库的导入方式也类似，以RabbitMQ和Modern Erlang仓库为例：

sudo rpm --import https://github.com/rabbitmq/signing-keys/releases/download/2.0/rabbitmq-release-signing-key.asc
sudo rpm --import https://packagecloud.io/rabbitmq/erlang/gpgkey
sudo rpm --import https://packagecloud.io/rabbitmq/rabbitmq-server/gpgkey

公钥只需要导入一次。后续安装或更新软件包时，Yum会自动使用已导入的公钥进行校验——前提是该公钥与软件包的签名能对上。

安装与更新的签名校验

当 gpgcheck=1 配置到位，且正确的公钥已经导入后，日常的安装和更新操作就变得非常透明。Yum会自动完成签名校验，你甚至感觉不到它的存在：

sudo yum install 
sudo yum update

如果需要只进行安全相关的更新，也可以使用 --security 参数：

sudo yum check-update --security
sudo yum update --security

唯一需要警惕的是那个 --nogpgcheck 选项，它允许跳过签名校验。这个选项存在的意义是应急，但强烈不建议在生产环境中使用。如果签名校验失败，意味着软件包可能被篡改或来源不可信，此时应该停下来排查原因，而不是直接绕过检查。

sudo yum install  --nogpgcheck

一句话总结：Yum默认启用签名验证，而签名失败就是安全报警。

对本地RPM包进行签名校验

有时候我们会手动下载RPM包进行安装。这种情况下，可以使用 rpm 工具直接校验：

rpm -K 
rpmkeys --checksig 

期望的输出中应该包含 OK 或 Good signature 等字样。如果看到 NOT OK 或 BAD signature，那就说明这个包有问题，不要安装。

对于非RPM的源码包（如 .tar.gz），很多项目会同时提供一个 .sig 签名文件。这时候可以用GPG来校验：

gpg --verify 

如果系统没有自动找到数据文件，也可以显式指定：

gpg --verify  

当然，在执行这些操作之前，先要确保已经导入了对应项目的公钥。

常见问题与排查

签名验证失败是运维中经常遇到的情况。遇到 GPG signature verification failed 时，可以从几个方面入手排查：

• 是否导入了正确的公钥？
• 仓库配置中的 gpgkey 路径是否正确？
• 系统时间是否准确？时间偏差过大也会导致签名验证失败。

第三方仓库的情况会更复杂一些。比如RabbitMQ，它需要导入多个密钥，并且建议同时开启 repo_gpgcheck=1 和 gpgcheck=1。这相当于上了双重保险。

修改仓库配置或密钥之后，最好清理并重建一下Yum的元数据缓存：

sudo yum clean all
sudo yum makecache

最后，一个非常现实的安全建议：在生产环境中，不要长期关闭 gpgcheck。如果实在需要临时绕过，请在安装完成后立即恢复配置，并重新校验已安装的软件包。安全这根弦，松不得。