1. 问题现象与背景解析
最近在Ubuntu 24.04系统上执行sudo apt update时,不少用户遇到了一个特殊警告提示:"N: 对‘http://cz.archive.ubuntu.com/ubuntu’在sources.list(5)一项中缺失了Signed-By"。这个看似无害的提示背后,实际上反映了Ubuntu新版本在软件源安全验证机制上的重要变化。
作为从Ubuntu 22.04就开始使用APT包管理系统的老用户,我注意到这个报错在24.04版本中首次高频出现。经过分析,这是Ubuntu为了增强软件源安全性而引入的严格验证机制——所有通过HTTPS连接的官方软件源现在必须明确指定用于验证的GPG密钥(即Signed-By字段)。这种变化虽然增加了安全性,但也导致了许多用户更新系统时遇到困惑。
注意:这个警告不会阻止apt的正常运作,但忽略它可能导致未来无法验证软件包的真实性,存在潜在安全风险。
2. 问题根源深度剖析
2.1 Signed-By字段的作用机制
Signed-By是Debian/Ubuntu软件源配置中的关键安全字段,它指定了用于验证该软件源发布包签名的GPG公钥。当APT从软件源下载软件包时,会:
- 使用该字段指定的密钥验证软件包签名
- 确保软件包确实来自受信任的发布者
- 防止中间人攻击或镜像站被篡改的风险
在Ubuntu 24.04之前,系统会默认使用系统全局信任的密钥环(/etc/apt/trusted.gpg.d/)中的密钥进行验证。但新版本要求每个软件源显式声明其使用的签名密钥,这提供了更细粒度的安全控制。
2.2 配置文件结构解析
Ubuntu的软件源配置文件主要存放在两个位置:
/etc/apt/sources.list(主配置文件)/etc/apt/sources.list.d/目录下的.list文件(附加配置)
一个完整的软件源条目应该包含以下字段:
code复制Types: deb/deb-src
URIs: 镜像站URL
Suites: 发行版代号(jammy等)
Components: main/restricted等
Signed-By: GPG密钥路径
缺失Signed-By字段时,APT虽然仍能工作,但会发出警告提示验证环节存在安全隐患。
3. 问题解决方案详解
3.1 定位问题文件
首先需要确定具体是哪个配置文件缺少Signed-By字段。可以通过以下命令查看所有软件源配置:
bash复制grep -r "cz.archive.ubuntu.com" /etc/apt/sources.list /etc/apt/sources.list.d/
通常问题会出现在/etc/apt/sources.list.d/目录下的某个.list文件中。在我的案例中,问题文件是/etc/apt/sources.list.d/archive_uri-http_cz_archive_ubuntu_com_ubuntu-jammy.list。
3.2 获取正确的GPG密钥
Ubuntu官方软件源的GPG密钥通常已经存在于系统中,位于:
code复制/usr/share/keyrings/ubuntu-archive-keyring.gpg
可以通过以下命令验证密钥是否存在:
bash复制sudo apt install ubuntu-archive-keyring
ls -l /usr/share/keyrings/ubuntu-archive-keyring.gpg
3.3 编辑配置文件
使用sudo权限打开问题文件(以nano为例):
bash复制sudo nano /etc/apt/sources.list.d/archive_uri-http_cz_archive_ubuntu_com_ubuntu-jammy.list
将文件内容修改为如下格式(以jammy为例):
code复制Types: deb
URIs: http://cz.archive.ubuntu.com/ubuntu
Suites: jammy
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg
3.4 验证修改结果
保存文件后,执行以下命令测试配置是否正确:
bash复制sudo apt update
如果不再出现"缺失Signed-By"的警告,说明问题已解决。
4. 深入原理与高级配置
4.1 密钥管理机制
Ubuntu使用分层密钥体系:
- 主发布密钥:验证发行版元数据
- 软件包签名密钥:验证单个软件包
- 镜像站密钥:验证镜像站内容一致性
ubuntu-archive-keyring.gpg包含了所有这些必要密钥,因此指定它就能完成完整的验证链。
4.2 自定义软件源配置
对于第三方软件源,正确的Signed-By配置方法是:
- 获取软件提供方的GPG公钥
- 将密钥保存到
/usr/share/keyrings/目录 - 在软件源配置中指定该密钥路径
例如,Docker的配置示范:
code复制deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu jammy stable
4.3 密钥更新策略
Ubuntu的密钥会定期更新,系统更新时会自动处理。但如果你手动修改过密钥配置,可能需要关注以下目录:
/usr/share/keyrings/:用户和管理员安装的密钥/etc/apt/trusted.gpg.d/:系统全局信任的密钥
5. 常见问题排查指南
5.1 修改后仍然报错
如果添加Signed-By后仍报错,可能是:
- 密钥路径错误:确认
/usr/share/keyrings/ubuntu-archive-keyring.gpg存在 - 文件权限问题:确保密钥文件可读(权限644)
- 缓存未更新:尝试
sudo apt clean后再update
5.2 密钥验证失败
出现"NO_PUBKEY"错误时,需要手动导入密钥:
bash复制sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys <缺失的密钥ID>
5.3 混合使用HTTP和HTTPS源
虽然Ubuntu允许HTTP连接,但强烈建议将所有源改为HTTPS:
- 修改URI中的http为https
- 确保镜像站支持HTTPS
- 更新Signed-By配置
6. 最佳实践建议
经过多次实际调试,我总结了以下经验:
- 统一管理原则:将所有软件源配置迁移到
/etc/apt/sources.list.d/目录,每个服务一个文件 - 注释说明:在每个配置文件中添加注释说明来源和最后修改时间
- 定期审核:每季度检查一次软件源配置,移除不再使用的源
- 备份策略:修改前备份原始配置:
sudo cp /etc/apt/sources.list.d/xxx.list ~/backup/ - 验证工具:使用
apt-config dump命令检查最终生效的配置
对于企业环境,还可以考虑:
- 设置内部APT镜像站
- 使用Ansible等工具统一管理配置
- 实现配置变更的版本控制
7. 系统升级注意事项
从Ubuntu 22.04升级到24.04时,特别需要注意:
- 升级前备份所有软件源配置
- 升级后检查
/etc/apt/sources.list.d/下的文件 - 将原有的
deb http://...格式转换为新的多行格式 - 测试每个软件源的连接和验证是否正常
一个实用的检查脚本:
bash复制#!/bin/bash
for f in /etc/apt/sources.list.d/*.list; do
echo "Checking $f"
grep -q "Signed-By" "$f" || echo "WARNING: Missing Signed-By in $f"
done
这个报错虽然看起来是个小问题,但它反映了Linux发行版在软件供应链安全上的持续改进。作为系统管理员,理解并正确配置这些安全机制,是确保系统长期稳定运行的基础。我在实际工作中发现,越是严格的安全警告,越能帮助我们提前发现潜在问题。