1. 问题初探：当熟悉的更新命令突然“罢工”
相信每一位Ubuntu或Debian系Linux的用户，对sudo apt update这条命令都再熟悉不过了。它就像每天早晨的例行检查，确保你的软件仓库列表是最新的，为后续的安装或升级铺平道路。然而，某一天，这条温顺的命令突然“翻了脸”，在终端里抛出一串令人不安的红色错误信息，核心内容就是：“由于没有公钥，无法验证下列签名：NO_PUBKEY XXXXXXXXXXXXXXXX”。那一刻，感觉就像家里的门锁突然换了，而你手里的旧钥匙怎么也插不进去了。
这个错误绝非个例，它几乎是所有Linux用户，从新手到老鸟，在系统维护路上必然会遇到的“经典关卡”。错误信息本身指向了一个核心的安全机制：APT（Advanced Package Tool）使用GPG（GNU Privacy Guard）密钥来验证从软件源下载的软件包索引文件的真实性和完整性。简单来说，每个软件仓库都有一把独一无二的“私钥”用来给它的数据“签名”，而你的系统需要持有对应的“公钥”才能“验签”，确认这些数据确实来自你信任的源头，而非被篡改或冒充的恶意服务器。
那么，为什么之前好好的，突然就找不到“公钥”了呢？原因通常集中在以下几点：你新添加了一个第三方软件源（PPA），但添加源的操作只提供了仓库地址，没有自动导入对应的GPG密钥；系统内某个已有软件源的GPG密钥过期了（密钥通常有有效期）；或者在极少数情况下，系统密钥环（keyring）受损或部分密钥被意外删除。无论哪种情况，其结果就是APT拒绝从该源更新索引，因为它无法验证数据的真实性，这是一种至关重要的安全保护措施，防止你安装来路不明的软件。
面对这个错误，新手可能会感到困惑甚至焦虑，担心系统出了大问题。而老手则知道，这通常是一个可以快速修复的“小插曲”。接下来，我们就深入这个“小插曲”的内部，拆解其原理，并给出从基础到进阶的完整解决方案。
2. 核心原理拆解：APT、GPG与信任链
要彻底解决公钥问题，我们不能停留在“运行某条命令”的层面，必须理解其背后的工作原理。这涉及到三个核心角色：APT、GPG和软件源仓库。
2.1 APT的工作流程与安全验证
APT并非简单地下载和安装软件。它的工作流程，特别是apt update阶段，包含严格的安全校验：
- 读取源列表：APT首先读取
/etc/apt/sources.list文件以及/etc/apt/sources.list.d/目录下的所有.list文件，获取所有已配置的软件仓库地址。 - 下载InRelease/Release.gpg文件：对于每个仓库，APT会尝试下载
InRelease文件（一个内嵌签名的Release文件）或Release文件加上独立的Release.gpg签名文件。这些文件包含了仓库中所有软件包索引（如Packages.gz）的哈希值列表。 - GPG验证：这是关键一步。APT使用本地系统密钥环中存储的、与该仓库对应的GPG公钥，去验证
Release.gpg签名或InRelease文件内嵌的签名。验证过程是解密签名信息，并与实际Release文件的内容进行比对。 - 哈希校验：只有在上一步签名验证通过后，APT才信任这个
Release文件。接着，它会根据该文件中列出的哈希值，去校验接下来下载的Packages.gz等索引文件。如果哈希值对不上，说明索引文件在传输过程中被损坏或篡改，APT会报错。 - 更新本地索引：只有当所有校验都通过后，APT才会用新的索引文件替换旧的，
apt update才算成功。
可以看到，GPG公钥是建立这条“信任链”的起点。没有正确的公钥，第一步验证就失败了，整个更新流程便会中止。
2.2 GPG密钥体系：公钥、私钥与密钥环
我们可以用一个简单的类比来理解GPG在其中的作用：
- 软件源维护者：他有一个独一无二的私钥（就像他自己的印章或手写签名）。每次发布新的软件索引时，他都会用这个私钥对索引的摘要信息进行加密，生成一个“数字签名”。
- 你的Ubuntu系统：你需要拥有该维护者的公钥（就像他公开的印章印模或签名样本）。这个公钥无法用来伪造签名，但可以用来解密那个签名，并验证解密后的信息是否与收到的索引摘要匹配。
- 验证过程：你收到索引文件和他的签名。你用他的公钥去解密签名，得到一串信息A。同时，你自己计算收到索引的摘要，得到信息B。如果A等于B，就证明这份索引确实是他用对应的私钥签发的，且内容完整无误。
在Ubuntu系统中，这些受信任的公钥存储在一个特殊的“钥匙串”里，称为密钥环（keyring）。默认的系统密钥环文件通常位于/etc/apt/trusted.gpg或/usr/share/keyrings/目录下，以及trusted.gpg.d/子目录中。apt-key命令（虽然已逐渐被弃用）就是用来管理这个密钥环的工具。
2.3 错误根源深度分析
理解了原理，我们再回头看错误信息NO_PUBKEY XXXXXXXXXXXXXXXX。这里的XXXXXXXXXXXXXXXX是缺失公钥的ID的后16位（或8位）短ID。它明确告诉你：“在验证来自某个仓库的数据时，我需要一个ID为XXXX...的公钥，但在我的密钥环里没找到它。”
导致这个“找不到”的常见场景有：
- 新增PPA未自动导入密钥：使用
add-apt-repository命令添加官方支持的PPA时，该命令通常会帮你自动下载并导入密钥。但如果你手动在/etc/apt/sources.list.d/里添加了一个.list文件，或者某些非Ubuntu官方源的安装脚本遗漏了这一步，就会导致此错误。 - 密钥过期：GPG密钥可以设置有效期。一些仓库的密钥可能已经过期。虽然过期的密钥在手动验证时可能会产生警告，但APT的严格模式会直接将其视为无效。
- 密钥环被破坏或部分丢失：极少数情况下，对
/etc/apt/trusted.gpg文件的误操作或某些有问题的脚本可能会损坏密钥环。 - 仓库变更了签名密钥：软件源维护者可能更新了他们的GPG密钥对。如果仓库服务器已经使用新密钥签名，而你的本地没有新公钥，也会报错。
注意：过去常用的
apt-key add命令已被标记为弃用，因为它将所有密钥都添加到全局受信列表 (/etc/apt/trusted.gpg) 中，存在潜在的安全风险。现在推荐的做法是将密钥文件单独存放在/etc/apt/trusted.gpg.d/目录（ASCII-armored格式）或/usr/share/keyrings/目录（二进制格式），并在源文件中通过[signed-by=/path/to/keyfile.gpg]语法明确指定该源使用的密钥。这实现了更细粒度的信任管理。
3. 标准解决方案：一步步找回丢失的“钥匙”
当错误发生时，终端输出的错误信息通常会明确告诉你是哪个仓库出了问题。例如：
W: GPG error: https://example.com/ubuntu jammy InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 871920D1991BC93C这里，仓库URL是https://example.com/ubuntu，缺失的公钥ID是871920D1991BC93C。我们的目标就是获取这个ID对应的公钥，并将其安全地添加到系统中。
3.1 方法一：使用apt-key命令（传统/过渡方法）
尽管不推荐，但在某些旧教程或简单排查时，你可能会遇到这个方法。了解它有助于处理历史遗留问题。
首先，通过公钥ID从Ubuntu密钥服务器获取公钥：
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 871920D1991BC93C--keyserver：指定密钥服务器，keyserver.ubuntu.com是最常用的。--recv-keys：后面跟上你需要获取的公钥ID。
命令成功执行后，输出会显示“gpg: key XXXXXXXXXXXXXXXX: public key "Some Developer email@example.com " imported”。此时，公钥已被添加到全局可信密钥环 (/etc/apt/trusted.gpg) 中。
然后，再次运行sudo apt update，错误应该就会消失。
为什么不推荐？因为apt-key将密钥添加到全局信任库，这意味着所有软件源都会信任这个密钥，这违背了最小权限原则。如果这个密钥后来被泄露或用于恶意签名，会影响所有源的安全性。因此，这只是权宜之计。
3.2 方法二：现代推荐方法——下载并指定密钥文件
这是当前Ubuntu社区推荐的最佳实践，实现了源与密钥的精确绑定。
步骤1：下载公钥文件我们不再将密钥添加到全局环，而是将其下载为一个独立的文件。通常下载到/usr/share/keyrings/目录（需要sudo权限）。
sudo gpg --no-default-keyring --keyring /usr/share/keyrings/example-archive-keyring.gpg --keyserver keyserver.ubuntu.com --recv-keys 871920D1991BC93C--no-default-keyring：不使用默认密钥环。--keyring：指定一个新的密钥环文件路径，我们将公钥导入到这个单独的文件中。- 执行后，密钥就被保存在
/usr/share/keyrings/example-archive-keyring.gpg这个独立的二进制文件里。
或者，有时仓库会直接提供一个.asc格式的公钥文件链接，你可以用wget或curl下载：
sudo wget -O /usr/share/keyrings/example-archive-keyring.gpg https://example.com/example-key.gpg # 如果下载的是.asc文本格式，可能需要用gpg --dearmor转换 # sudo wget -O- https://example.com/example-key.asc | sudo gpg --dearmor -o /usr/share/keyrings/example-archive-keyring.gpg步骤2：修改软件源文件，关联密钥找到该仓库对应的源文件。如果它是通过PPA添加的，可能在/etc/apt/sources.list.d/下有一个类似example-ppa.list的文件；如果是手动添加的，可能在sources.list或.d/目录下的某个文件。
打开这个文件，修改其格式。原来的行可能长这样：
deb https://example.com/ubuntu jammy main修改为：
deb [signed-by=/usr/share/keyrings/example-archive-keyring.gpg] https://example.com/ubuntu jammy main关键是在deb后增加了[signed-by=/path/to/keyfile.gpg]选项，明确告诉APT：“验证这个仓库的签名时，请使用我指定的这个密钥文件。”
步骤3：更新并验证保存文件后，再次运行sudo apt update。这次，APT会使用你指定的密钥文件去验证该仓库，错误应当被解决。
3.3 方法三：针对特定PPA的快速修复
如果你确定错误来自一个Launchpad上的PPA（Ubuntu最常用的第三方软件源平台），并且当初是用add-apt-repository添加的，那么有时重新添加一遍可以自动修复密钥问题。
首先，你可以尝试移除这个PPA（这不会移除你已经安装的软件）：
sudo add-apt-repository --remove ppa:some-ppa/ppa然后，再重新添加它：
sudo add-apt-repository ppa:some-ppa/ppaadd-apt-repository脚本会重新获取仓库信息并导入最新的密钥。之后，再运行sudo apt update。
实操心得：在修改任何
/etc/apt/下的配置文件前，养成先备份的好习惯。例如，sudo cp /etc/apt/sources.list /etc/apt/sources.list.backup。这样一旦操作失误，可以迅速回滚。对于复杂的源配置，我习惯在修改后使用apt update --dry-run来模拟更新，检查是否有语法错误，然后再执行真正的更新。
4. 进阶排查与疑难杂症处理
有时候，按照标准流程操作后问题依旧，或者遇到更复杂的情况。这就需要一些进阶的排查手段。
4.1 确认密钥ID与源地址的对应关系
首先，必须确保你获取的公钥ID和报错的仓库是匹配的。一个密钥可能用于签名多个仓库，但一个仓库在特定时期通常只用一对密钥。你可以通过访问软件源的官方网站或文档，查找其公布的GPG公钥ID或下载链接。不要盲目地从网上搜索一个ID就添加，这存在安全风险。
4.2 处理过期的密钥
如果错误信息中暗示密钥已过期（虽然NO_PUBKEY错误不直接显示，但后续操作如apt upgrade可能遇到），你需要获取该仓库的新密钥。方法和上述一样，只是你需要找到仓库提供的新公钥ID或文件。有些仓库会在旧密钥过期前，同时用新旧两个密钥签名一段时间，以留出过渡期。你需要同时拥有新旧两个密钥，才能顺利过渡。
4.3 检查并修复密钥环文件权限与完整性
极少数情况下，系统密钥环文件可能权限错误或损坏。你可以检查相关目录的权限：
ls -l /etc/apt/trusted.gpg /etc/apt/trusted.gpg.d/ /usr/share/keyrings/这些文件通常应为root用户所有，且对普通用户可读。如果权限异常，可以使用sudo chmod和sudo chown修正。
如果怀疑某个全局密钥环文件损坏，可以尝试将其移走（备份），然后看问题是否变化：
sudo mv /etc/apt/trusted.gpg /etc/apt/trusted.gpg.backup sudo apt update如果错误消失，说明那个文件可能有问题。但请注意，这会移除所有通过旧方法（如apt-key add）添加的全局密钥。你需要重新为每个需要的源添加密钥（推荐用方法二）。
4.4 网络问题与密钥服务器
gpg --recv-keys命令需要连接密钥服务器（如keyserver.ubuntu.com）。如果你的网络环境无法访问这些服务器，命令会失败。可以尝试更换密钥服务器，例如使用hkp://keyserver.ubuntu.com:80或hkp://pgp.mit.edu:11371。如果所有密钥服务器都无法访问，那就必须通过其他方式（如从仓库官网直接下载公钥文件）来获取密钥。
4.5 处理多个错误与依赖关系
有时你会遇到多个NO_PUBKEY错误。这通常意味着你添加了多个第三方源，且它们的密钥都缺失。你需要对每一个缺失的密钥ID重复上述导入操作。务必一个一个来，并确保密钥与源对应正确，避免混乱。
5. 防患于未然：最佳实践与安全建议
解决眼前的问题固然重要，但建立良好的习惯更能让你避免未来的麻烦。
1. 优先使用官方源和主流PPA：Ubuntu官方源和Launchpad上经过验证的、活跃的PPA，其密钥管理通常更规范，自动导入的成功率也更高。尽量避免添加来源不明、文档不全的第三方源。
2. 使用add-apt-repository添加PPA：这个命令是添加PPA的标准方式，它会自动处理源列表和GPG密钥的添加。比手动编辑文件更可靠。
3. 采用“每源一钥”的现代配置：正如方法二所示，坚持为每个第三方源使用独立的.gpg密钥文件，并在源文件中用[signed-by]指定。这提升了系统的安全性和可维护性。你可以很容易地通过删除源文件和对应的密钥文件来彻底移除一个软件源。
4. 定期检查与更新：虽然不常见，但关注你所用第三方源的动态（如官网、GitHub页面），了解其密钥是否有变更计划。在执行重大系统升级（如从Ubuntu 20.04升级到22.04）后，记得检查第三方源是否兼容新版本，密钥是否需要更新。
5. 理解错误信息：不要害怕终端输出的错误信息。像NO_PUBKEY这类错误，其信息非常明确：缺失的密钥ID和对应的仓库URL。学会阅读并理解这些信息，是独立解决Linux系统问题的关键能力。
6. 备份你的源列表：将/etc/apt/sources.list和/etc/apt/sources.list.d/目录下的所有文件备份到安全的地方（如家目录下的一个文件夹，或版本控制系统）。当你需要在新机器上重建环境，或者当前系统配置被意外破坏时，这些备份能节省大量时间。
6. 常见问题速查与现场实录
在实际操作中，你可能会遇到一些看似类似但根源不同的问题，或者一些典型的困惑。这里记录几个常见场景：
Q1: 我运行了sudo apt-key adv ...，但提示“gpg: keyserver receive failed: No data”。A1:这通常是网络问题或密钥服务器暂时无响应。尝试： * 更换密钥服务器：将keyserver.ubuntu.com换成hkp://keyserver.ubuntu.com:80或pgp.mit.edu。 * 检查网络连接和防火墙设置。 * 稍后再试，可能是服务器端临时问题。
Q2: 我按照方法二操作了，但apt update还是报同样的错。A2:请按以下步骤排查： 1.检查路径：确保[signed-by=]中的文件路径完全正确，文件确实存在。 2.检查文件格式：用file命令检查密钥文件格式：file /usr/share/keyrings/example.gpg。它应该显示“GPG key public ring”。如果你下载的是.asc文本文件但没有用gpg --dearmor转换，APT可能无法识别。重新用gpg --dearmor转换即可。 3.检查源文件语法：确保[signed-by=...]和URL之间有一个空格。例如deb [signed-by=...] https://...。 4.清除APT缓存：有时旧的缓存会引起混淆。运行sudo apt clean和sudo rm -rf /var/lib/apt/lists/*（注意：这会删除所有软件包列表缓存），然后再次sudo apt update。
Q3: 错误信息里有很多个NO_PUBKEY，我需要一个个手动添加吗？A3:是的， safest way 是逐个添加，并确保每个密钥对应正确的源。可以写一个简单的Shell脚本来批量处理，但前提是你必须清楚每个密钥ID对应的源，且信任所有这些源。批量操作的风险在于，如果脚本中混入了一个错误或不信任的密钥ID，会降低系统安全性。
Q4: 除了NO_PUBKEY，我还看到KEYEXPIRED错误，怎么办？A4:KEYEXPIRED明确表示密钥已过期。你需要从该软件源的官方渠道获取其新的公钥。获取方式同样是通过其文档提供的ID从密钥服务器获取，或直接下载新的公钥文件，然后用新密钥替换旧密钥文件（或添加到系统中）。在过渡期内，系统可能需要同时拥有新旧两个密钥才能顺利更新。
Q5: 这个方法适用于所有基于Debian/APT的Linux吗？比如Linux Mint、Kali？A5:是的，完全适用。APT和GPG验证机制是Debian及其衍生发行版（包括Ubuntu, Linux Mint, Kali Linux, elementary OS等）共用的核心组件。解决NO_PUBKEY错误的原理和方法在所有这些发行版上都是相同的。只是系统密钥环的默认路径可能略有差异，但现代方法（使用独立密钥文件）的路径是通用的。
遇到ubuntu apt update报错：由于没有公钥，无法验证下列签名，从最初的困惑到最终解决，这个过程本身就是一次对Linux系统安全更新机制的深入理解。它提醒我们，在开源世界的便捷背后，是一套严谨的信任验证体系在保驾护航。掌握处理这个错误的方法，不仅是解决了一个具体问题，更是获得了维护系统安全与稳定的一项关键技能。下次再看到它时，你大可以淡定地打开终端，因为你知道，这只是系统在尽职尽责地要求你确认一下软件源的“身份证”而已。