1. 问题现象与背景分析

最近在Ubuntu 24.04 LTS系统上执行常规系统更新后，不少用户遇到了一个典型的报错提示："sources.list(5)中缺少Signed-By字段"。这个错误通常在执行apt update命令时出现，会导致软件源更新失败。作为长期使用Ubuntu的开发者，我最近在升级工作站的系统后也遇到了同样的问题。

这个报错的本质是Ubuntu 24.04加强了对软件源的安全验证机制。从技术层面看，Signed-By是APT包管理器用于验证软件仓库签名的新要求，它确保了软件源的真实性和完整性。在之前的版本中，这个字段在某些情况下是可选的，但在24.04中变成了强制要求。

2. 问题根源深度解析

2.1 Signed-By字段的作用机制

Signed-By字段在sources.list文件中扮演着数字签名的角色。它通过指定一个GPG密钥来验证从软件源下载的元数据（如Packages.gz文件）是否经过授权。具体工作流程如下：

1. 系统通过HTTPS下载软件包列表
2. 使用指定的GPG密钥验证下载内容的签名
3. 只有验证通过的软件包才会被安装

这种机制有效防止了中间人攻击和软件源被篡改的风险。Ubuntu 24.04之所以强制要求这个字段，是为了响应近年来软件供应链攻击增多的安全趋势。

2.2 典型报错场景分析

根据我的实际排查经验，这个问题通常出现在以下几种情况：

1. 系统升级后：从22.04升级到24.04时，旧的sources.list配置可能不符合新要求
2. 手动添加第三方源：特别是那些没有提供签名密钥的仓库
3. 使用PPA源：部分PPA没有及时更新他们的发布方式

典型的错误信息格式如下：

E: 仓库"http://xx.xx.xx.xx jammy Release" 在sources.list(5)中缺少Signed-By字段

3. 完整解决方案

3.1 基础修复方法

对于大多数官方源和主流第三方源，最简单的修复方法是重新生成sources.list文件：

sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak # 先备份 sudo sed -i '/^deb/ s/$/ signed-by=\/usr\/share\/keyrings\/ubuntu-archive-keyring.gpg/' /etc/apt/sources.list

这个命令会自动为所有deb行添加正确的Signed-By字段指向系统默认密钥环。

3.2 处理第三方源的特殊情况

对于第三方源，需要先获取其GPG密钥并添加到密钥环中。以Docker CE源为例：

# 下载密钥 sudo mkdir -p /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg # 修改源配置 echo "deb [signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu jammy stable" | sudo tee /etc/apt/sources.list.d/docker.list

3.3 针对PPA源的解决方案

Ubuntu的PPA源需要特殊处理，因为它们的密钥管理方式不同：

# 对于已有PPA sudo add-apt-repository --remove ppa:someppa/ppa sudo add-apt-repository ppa:someppa/ppa # 或者手动修改 sudo sed -i 's|^deb http://ppa.launchpad.net|deb [signed-by=/etc/apt/trusted.gpg.d/ppa.gpg] http://ppa.launchpad.net|' /etc/apt/sources.list.d/*.list

4. 深入排查与高级技巧

4.1 密钥管理最佳实践

在Ubuntu 24.04中，建议将所有GPG密钥统一存放在/usr/share/keyrings/目录下，并确保权限正确：

sudo chmod 644 /usr/share/keyrings/*.gpg sudo chown root:root /usr/share/keyrings/*.gpg

可以使用以下命令验证密钥是否被正确识别：

sudo apt-key list

4.2 自动化检查脚本

我开发了一个简单的检查脚本，可以快速找出所有缺少Signed-By字段的源：

#!/bin/bash for file in /etc/apt/sources.list /etc/apt/sources.list.d/*; do echo "Checking $file" grep -P '^deb(?!.*signed-by=)' "$file" && echo "Found unsigned entries in $file" done

4.3 临时解决方案的风险

虽然可以通过修改APT配置临时禁用签名验证，但这会严重降低系统安全性：

# 不推荐！仅用于紧急情况 sudo sh -c 'echo "APT::Get::AllowUnauthenticated "true";" > /etc/apt/apt.conf.d/99allow-unauth'

5. 常见问题与疑难解答

5.1 密钥导入失败问题

当遇到"NO_PUBKEY"错误时，可以通过以下方式解决：

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys MISSING_KEY_ID

如果标准密钥服务器不可用，可以尝试：

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys MISSING_KEY_ID

5.2 混合源配置问题

当系统中同时存在新旧格式的源配置时，建议统一格式。可以使用这个命令转换旧格式：

sudo sed -i 's|^deb \(.*\) \(.*\) \(.*\)$|deb [signed-by=/usr/share/keyrings/ubuntu-archive-keyring.gpg] \1 \2 \3|' /etc/apt/sources.list

5.3 企业内网源的特殊处理

对于内网软件源，如果无法提供签名，可以创建自签名证书：

# 生成密钥 gpg --batch --generate-key <<EOF Key-Type: RSA Key-Length: 2048 Name-Real: Internal Repo Expire-Date: 0 %no-protection EOF # 导出公钥 gpg --output /usr/share/keyrings/internal-repo.gpg --export "Internal Repo"

然后在sources.list中使用这个密钥路径。

6. 预防措施与最佳实践

为了避免将来出现类似问题，我建议采取以下预防措施：

1. 定期检查源配置：每月检查一次/etc/apt/sources.list*文件
2. 使用官方源：尽可能使用Ubuntu官方源和知名第三方源
3. 文档化变更：每次修改源配置都记录变更内容和原因
4. 备份配置：备份原始sources.list文件

对于系统管理员，可以考虑实现配置管理自动化，例如使用Ansible角色来管理APT源：

- name: Ensure APT sources are properly configured apt_repository: repo: "deb [signed-by=/usr/share/keyrings/ubuntu-archive-keyring.gpg] http://archive.ubuntu.com/ubuntu {{ ansible_distribution_release }} main restricted" state: present filename: official-sources.list

在实际工作中，我发现保持软件源配置的整洁和规范可以避免90%以上的APT相关问题。Ubuntu 24.04的这个变化虽然初期带来了一些适配工作，但从长远看大大提升了系统的安全性。