1. 问题现象与核心原因剖析如果你在Ubuntu或者基于Debian的Linux发行版上执行sudo apt update命令时终端里突然蹦出类似下面这样的错误信息那感觉就像开车时仪表盘突然亮起一个看不懂的警告灯让人心里一咯噔W: GPG error: http://ppa.launchpad.net/example/ppa/ubuntu jammy InRelease: The following signatures couldnt be verified because the public key is not available: NO_PUBKEY 1234567890ABCDEF E: The repository http://ppa.launchpad.net/example/ppa/ubuntu jammy InRelease is not signed.或者更简洁的版本W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://example.com/repo stable InRelease: The following signatures were invalid: EXPKEYSIG 1234567890ABCDEF Some Repository这个错误的核心就藏在“公钥”和“签名”这两个词里。简单来说Ubuntu的软件仓库Repository为了确保你下载的软件包是官方原版、没有被中途篡改或植入恶意代码采用了GPG加密签名机制。每个软件仓库的维护者都有一对“密钥”一把私钥自己保管用来给软件包索引文件签名一把公钥公开发布让所有用户用来验证签名。当你执行apt update时系统会从配置的软件源地址下载一个名为InRelease或Release.gpg的文件这个文件包含了软件包列表的哈希值和用私钥生成的数字签名。你的系统会尝试用本地对应的公钥去验证这个签名。如果验证通过说明这个软件列表是可信的如果验证失败apt就会报错并拒绝从这个源更新软件列表以此保护你的系统安全。那么为什么会出现“没有公钥”的错误呢最常见的原因有以下几种添加了新的PPAPersonal Package Archive或第三方软件源这是最典型的场景。很多开发者或社区会通过Launchpad等平台提供PPA方便用户安装最新或特定版本的软件。当你用add-apt-repository命令添加一个PPA时这个命令通常会帮你自动下载并注册对应的公钥。但如果这个自动过程失败了比如网络问题、PPA已迁移或废弃或者你是手动在/etc/apt/sources.list.d/目录下添加的源文件公钥就不会被自动导入。软件源更换了签名密钥维护者可能因为安全原因更新了他们的密钥对。旧公钥无法验证用新私钥签名的文件从而导致报错。公钥已过期GPG密钥通常有有效期。如果某个源的公钥过期了也会导致验证失败。系统时间错误GPG签名验证对时间非常敏感。如果你的系统时间严重不准比如偏差几个月或几年可能会导致签名在验证时被视为“过期”或“尚未生效”从而引发错误。这个错误本身不会破坏你的系统但它会阻止你从报错的软件源更新软件列表。这意味着你无法从这个源安装新软件也无法获取该源中软件的安全更新存在潜在的安全风险。因此解决它不仅是让apt update变安静更是维护系统安全更新通道的重要一环。2. 诊断与排查定位“元凶”源在动手修复之前我们不能盲目操作。首先得搞清楚是哪个或哪几个软件源在“闹脾气”。apt update的错误输出已经给出了线索但我们需要更系统地查看。一个非常实用的命令是apt-key虽然在新版Debian/Ubuntu中它已被标记为弃用deprecated但在许多现有系统上用它来列出当前信任的所有公钥依然是最直观的方式。在终端输入sudo apt-key list这个命令会输出一长串列表显示当前系统中所有已受信任的GPG公钥。每一条记录通常包括密钥ID例如pub rsa4096 2021-01-01 [SC] [expires: 2026-01-01]下面一行的ABCD1234...、指纹、创建日期和所属UID通常是仓库维护者的名称或邮箱。现在回到apt update的错误信息。错误信息里包含了一个关键的字符串NO_PUBKEY 1234567890ABCDEF。这里的1234567890ABCDEF就是缺失的那个公钥的长密钥ID通常是16位十六进制数。有时候错误信息也可能显示EXPKEYSIG后面跟着类似的ID这表示密钥过期了。你的任务就是拿着这个缺失的密钥ID例如1234567890ABCDEF去sudo apt-key list的输出结果里搜索。如果搜不到那就确认了这个密钥确实不在系统的受信任密钥环中。如果找到了但错误提示是EXPKEYSIG那就说明找到的密钥已经过期了。除了apt-key我们还可以直接检查软件源配置文件看看是哪个文件引入了这个有问题的源系统主源列表/etc/apt/sources.list附加源列表目录/etc/apt/sources.list.d/这个目录下的每一个.list文件都代表一个独立的软件源。你可以用cat或grep命令来查看这些文件的内容寻找错误信息中提到的仓库URL例如http://ppa.launchpad.net/example/ppa/ubuntu。注意在排查时请务必留意那些你不再使用或来源不明的第三方源。有些软件源可能已经停止维护其密钥自然也无法更新。长期保留这些源不仅会导致更新报错还可能带来安全风险。对于不确认的源最好的做法是注释掉在行首加#或直接删除对应的源文件。3. 核心解决方案获取并信任正确的公钥找到了缺失的密钥ID和对应的软件源接下来就是解决之道。我们将从最常见、最推荐的方法开始逐步介绍其他备选方案。3.1 首选方案使用apt-key adv从密钥服务器拉取这是解决因添加PPA或第三方源导致密钥缺失的标准且推荐的方法。它的原理是连接到全球的GPG密钥服务器网络如keyserver.ubuntu.com根据密钥ID下载对应的公钥并将其添加到系统的可信密钥环中。命令格式如下sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys [缺失的密钥ID]将[缺失的密钥ID]替换为错误信息中的那一串字符例如sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 1234567890ABCDEF执行过程与原理apt-key adv调用apt-key工具的高级模式。--keyserver keyserver.ubuntu.com指定密钥服务器。keyserver.ubuntu.com是 Ubuntu 社区最常用的密钥服务器绝大多数PPA和官方衍生源的密钥都能在这里找到。如果这个服务器连接不畅可以尝试hkp://keyserver.ubuntu.com:80或keys.gnupg.net。--recv-keys指令是接收receive指定的密钥。命令执行后系统会连接密钥服务器下载该ID对应的公钥并自动将其加入/etc/apt/trusted.gpg或/etc/apt/trusted.gpg.d/目录下的密钥环文件中。操作后验证 执行成功后通常会看到gpg: key 1234567890ABCDEF: public key \Some Developer someexample.com\ imported之类的提示。此时再次运行sudo apt-key list你应该能在列表中找到新导入的密钥。最后运行sudo apt update针对该源的错误信息应该就会消失。3.2 备选方案一从软件源仓库直接获取公钥文件有些软件源特别是一些企业级或独立的仓库会在其官方网站上直接提供公钥文件通常以.asc或.gpg为后缀。这种方法不依赖外部的密钥服务器在某些内网环境或密钥服务器访问不到时非常有用。操作步骤通常如下下载公钥文件使用wget或curl命令从源提供的URL下载。wget -O- https://example.com/repo/example-key.asc将公钥添加到APT信任列表将下载的内容公钥文本通过管道传递给apt-key add命令。wget -O- https://example.com/repo/example-key.asc | sudo apt-key add -或者如果你已经将文件下载到本地如example-key.ascsudo apt-key add ./example-key.asc为什么这样可行apt-key add命令可以直接读取包含公钥的文本文件内容并将其解析、加入到系统的可信密钥存储中。这种方式相当于“手动安装证书”确保了密钥来源的确定性。3.3 备选方案二使用add-apt-repository重新添加PPA如果你确定错误来源于某个之前通过ppa:格式添加的PPA并且apt-key adv方法失败了可能是因为PPA名称错误或已删除可以尝试先移除再重新添加。这个方法会触发Ubuntu的PPA添加脚本该脚本包含了自动获取和注册密钥的逻辑。# 首先移除有问题的PPA sudo add-apt-repository --remove ppa:example/ppa # 然后重新添加它确保PPA名称正确 sudo add-apt-repository ppa:example/ppa执行第二条命令时你会看到提示信息并需要按回车确认。如果PPA依然有效且网络正常重新添加的过程通常会成功解决密钥问题。3.4 针对密钥过期的处理方案如果错误信息是EXPKEYSIG说明密钥还在但过期了。对于由第三方PPA提供的源通常需要等待维护者发布并推送新的密钥。你可以尝试先移除该PPAsudo add-apt-repository --remove过一段时间再重新添加或者关注该软件项目的官方公告。对于非常重要的官方衍生源如某些显卡驱动仓库可以尝试从该源的官方文档中寻找更新密钥的方法有时会提供新的密钥ID让你手动导入即复用方案3.1。4. 现代系统的最佳实践与深入管理随着Debian/Ubuntu版本的更新传统的apt-key管理方式正在被更安全、更规范的方法取代。特别是在 Ubuntu 22.04 及更高版本中官方推荐将第三方源的GPG密钥以单独文件的形式存放在/etc/apt/trusted.gpg.d/目录下而不是全部混在同一个trusted.gpg文件里。同时软件源定义中也可以直接指向本地的密钥文件。新方法示例手动下载并放置密钥文件假设某个仓库要求你使用这种方法从仓库网站下载公钥文件例如myrepo.gpg。将其复制到/etc/apt/trusted.gpg.d/目录并确保文件权限正确。sudo cp myrepo.gpg /etc/apt/trusted.gpg.d/ sudo chmod 644 /etc/apt/trusted.gpg.d/myrepo.gpg在/etc/apt/sources.list.d/myrepo.list源文件中使用[signed-by/etc/apt/trusted.gpg.d/myrepo.gpg]的语法来指定该源使用的密钥。deb [signed-by/etc/apt/trusted.gpg.d/myrepo.gpg] https://repo.example.com/ubuntu stable main这种方法实现了“源-钥”严格绑定管理起来更清晰安全性也更高。当你删除某个源时可以一并删除其对应的密钥文件避免了密钥环的臃肿。系统时间校验如前所述系统时间错误会干扰GPG签名验证。如果你在排除了密钥问题后apt update仍然有奇怪的签名错误不妨检查一下系统时间date如果时间明显不对你可以使用timedatectl命令来设置网络时间同步sudo timedatectl set-ntp true sudo timedatectl set-timezone Asia/Shanghai # 设置时区例如上海等待几秒后再次检查date时间应该已经校准。这是一个容易被忽略但偶尔会跳出来“捣乱”的因素。5. 疑难杂症与进阶排查即使掌握了上述方法你仍可能遇到一些棘手的情况。下面是一些更深层次的排查思路。场景一apt-key adv命令执行失败提示“连接超时”或“找不到密钥”。这通常是网络问题或密钥ID不正确导致的。更换密钥服务器keyserver.ubuntu.com可能暂时无法访问。可以尝试其他常用服务器sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys KEY_ID sudo apt-key adv --keyserver keys.gnupg.net --recv-keys KEY_ID sudo apt-key adv --keyserver hkp://pgp.mit.edu:80 --recv-keys KEY_ID确认密钥ID确保你复制的密钥ID完整无误。有时错误信息显示的是密钥指纹40位的最后16位或8位而--recv-keys通常需要完整的16位长ID或8位短ID。可以尝试用错误信息中完整的指纹如果有来导入。检查源地址访问报错信息中的仓库URL看看其官方网站或说明文档是否提供了不同的密钥ID或特殊的安装说明。场景二处理遗留的apt-key警告向新规范迁移。在新版系统上执行sudo apt-key list你可能会看到警告Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead.这说明你的系统正在使用新的管理方式但还有一些旧密钥存放在旧的trusted.gpg文件中。迁移的关键是将旧密钥环中的特定密钥导出为单独文件。首先用apt-key list找到要迁移的密钥ID和其对应的指纹/描述。然后导出该密钥sudo apt-key export KEY_ID | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/myrepo-archive-keyring.gpg这条命令做了两件事apt-key export导出密钥gpg --dearmor将其转换为二进制格式.gpg文件。之后你需要修改对应的源文件.list文件添加[signed-by/etc/apt/trusted.gpg.d/myrepo-archive-keyring.gpg]选项。完成后理论上可以安全地用sudo apt-key del KEY_ID从旧密钥环中删除该密钥但操作前请务必确认新配置工作正常。场景三错误涉及多个密钥或多个源。如果apt update报出一连串不同的NO_PUBKEY错误不要慌张这通常意味着你添加了多个第三方源而它们的密钥都缺失了。解决方案就是“逐个击破”。针对每一个缺失的密钥ID重复执行sudo apt-key adv --recv-keys命令。耐心一点处理完一个再运行一次apt update确认该错误已解决再处理下一个。6. 防患于未然日常维护与最佳习惯与其在报错后四处查找解决方案不如养成良好的系统维护习惯从根本上减少这类问题的发生。谨慎添加第三方源只从可信赖的、活跃维护的项目或开发者那里添加PPA或第三方仓库。在添加前可以快速搜索一下该源的口碑看看是否有其他用户报告过类似问题。定期清理无用源定期检查/etc/apt/sources.list.d/目录移除那些不再使用的软件源配置文件。对于长期报“404 Not Found”或密钥错误的源应果断注释或删除。使用官方和主流镜像源将系统的软件源/etc/apt/sources.list设置为国内可靠的镜像站如阿里云、腾讯云、清华大学的镜像不仅可以加速更新其稳定性和密钥同步也通常更有保障。理解操作的含义当你执行add-apt-repository或手动添加源时心里要明白这背后系统在做什么添加了一个下载地址并试图获取一个用于验证的“数字证书”公钥。这有助于你在遇到问题时更快地定位方向。备份源列表在对/etc/apt/sources.list或/etc/apt/sources.list.d/下的文件进行重大修改前可以进行简单备份例如sudo cp /etc/apt/sources.list /etc/apt/sources.list.backup。“由于没有公钥无法验证下列签名”这个错误是Linux包管理系统安全机制的一个体现。它虽然带来了一点小麻烦但正是在提醒我们软件安装和更新的链条必须是可信的。通过本文的梳理从诊断、解决到预防你应该已经能够游刃有余地处理这个问题。下次再看到这个错误时你大可以自信地打开终端因为它不再是一个令人困惑的障碍而只是一个需要按照标准流程去修复的配置项。记住核心命令sudo apt-key adv --recv-keys并理解其背后的原理你就能保持apt更新通道的顺畅与安全。