遇到 Debian 或 Ubuntu 执行 apt update 弹出 W: There is no public key available for the following key IDs，不用重装系统，这通常只是某个第三方软件源缺少签名公钥，补齐 key 或换掉问题源，十分钟内就能让更新恢复正常。如果你刚好在用国内服务器的 Debian/Ubuntu 镜像，把 key 修好之后，apt 更新速度往往也会跟着稳下来。
debian更新提示没有公钥怎么办？先理解这行黄字到底卡在哪
很多人在 VPS 上第一次见到这行提示会下意识以为系统坏了，其实它只是 apt 在说：某个源里的软件包签名，我本地没有对应的公钥可以验证，apt 会把这个源暂时跳过,不会阻止系统自带仓库继续更新。
常见触发场景包括：
- 手动添加了 Docker、Nginx、MySQL、NodeSource 等第三方源，只写了
deb地址，没有配置signed-by公钥路径 - 从 Debian 10 升级到 Debian 11 或 Ubuntu 20.04 升级到 22.04，旧版
apt-key add导入的 key 不再被新的 keyring 机制读取 - 云厂商模板里预装的某个软件源公钥过期，或者模板制作时漏导了 key
- 本地
/etc/apt/trusted.gpg、/etc/apt/trusted.gpg.d/目录被误删、清空或权限损坏 - 换源脚本只替换了
/etc/apt/sources.list，没有同步替换/etc/apt/sources.list.d/下第三方源里的 key 路径
这行 W 之所以是黄字不是红字，就是因为它的严重级别不高，系统包管理器仍然可以正常更新 Ubuntu 官方 archive.ubuntu.com 或 Debian 官方 deb.debian.org 的安全补丁，只是被跳过那个源里的软件拿不到更新，对于跑着 Docker 或者 Node.js 生产服务的机器,这个跳过就不算小事了。
ubuntu apt update 公钥缺失解决方法：从缺失KEY到apt update不再报W
先抓取完整的 key ID
不要只扫一眼警告就急着搜命令，先把缺失的 key ID 拿到手：
sudo apt update 2>&1 | grep "NO_PUBKEY"多数时候会看到类似：
NO_PUBKEY 3B4FE6ACC0B21F32末尾那一串 3B4FE6ACC0B21F32 就是需要补充的 key ID，也有部分情况提示的是 The following signatures couldn't be verified because the public key is not available,这种同样能用下面方法处理。
选择导入公钥的正确姿势
最短的临时修复是用 apt-key：
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 3B4FE6ACC0B21F32
这条命令在旧版 Debian/Ubuntu 上很好用，但 apt-key 已经被官方标记为弃用，它在 Debian 11、Ubuntu 22.04 上仍然能执行，不过会打印一堆 deprecation 警告，更干净的做法是把 key 放进 /usr/share/keyrings/ 目录，再让源文件通过 signed-by 精确指向它：
sudo mkdir -p /usr/share/keyrings
sudo gpg --keyserver keyserver.ubuntu.com --recv-keys 3B4FE6ACC0B21F32
sudo gpg --export 3B4FE6ACC0B21F32 | sudo tee /usr/share/keyrings/custom.gpg >/dev/null然后检查 /etc/apt/sources.list.d/ 下对应源的 .list 文件,把原本的：
deb [arch=amd64] https://example.com/ubuntu jammy stable改成：
deb [arch=amd64 signed-by=/usr/share/keyrings/custom.gpg] https://example.com/ubuntu jammy stable如果不想改源文件，也可以直接把 key 放进 /etc/apt/trusted.gpg.d/：
sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/custom.gpg < keyfile这种方式比 apt-key 更集中，也更容易管理，但仍然属于全局信任，不如 signed-by 精准。
验证警告是否消失
执行：
sudo apt update如果之前那行 W 不再出现，说明 key 已经补对位置，还有个别源会继续提示，通常是源文件里 signed-by 路径与实际导出的 key 文件名不一致，用 grep -R "signed-by" /etc/apt/sources.list /etc/apt/sources.list.d/ 逐个核对即可。
国内服务器debian ubuntu公钥更新慢的另一个原因：keyserver连不上
国内不少服务器在执行 gpg --keyserver keyserver.ubuntu.com 时会卡很久，甚至直接超时，这并不代表 key 不存在，而是 key server 的访问链路不稳定。
遇到这种情况可以先试 80 端口：
sudo gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 3B4FE6ACC0B21F32如果还是慢，就别跟 keyserver 死磕，直接去软件源官方网站下载 GPG key 文件，再用 gpg --dearmor 转成 apt 可识别的格式，以 Docker 官方源为例：
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker.gpgNodeSource 的 key 也能直接下载：
curl -fsSL https://deb.nodesource.com/gpgkey/nodesource-repo.gpg.key | sudo gpg --dearmor -o /usr/share/keyrings/nodesource.gpg
这种直接从源站拿 key 的方式，比依赖公共 keyserver 更适合国内服务器环境，只要能访问对应软件源的下载地址，key 一般就不会卡住。
debian missing public key 修复实战：一台VPS换源后更新的复盘
说一个具体场景，一台 Debian 12 的 VPS，为了加速把系统源换成了简米云镜像，之后又在同一台机器上按照旧教程添加了 Docker 源，结果执行 apt update 时出现了：
W: GPG error: https://download.docker.com/linux/debian bookworm InRelease
The following signatures couldn't be verified because the public key is not available:
NO_PUBKEY 8D81803C0EBFCD88这里的问题不是简米云镜像，而是添加 Docker 源时只写了：
deb [arch=amd64] https://download.docker.com/linux/debian bookworm stable漏掉了官方文档里要求的 signed-by 参数，修复时先下载 Docker 官方的 GPG key：
curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker.gpg然后编辑 /etc/apt/sources.list.d/docker.list,改成：
deb [arch=amd64 signed-by=/usr/share/keyrings/docker.gpg] https://download.docker.com/linux/debian bookworm stable最后执行：
sudo apt updateW 提示消失，Docker 源开始正常刷新，这个过程和换源没有直接冲突，只是旧教程省略了 keyring 步骤导致的典型问题。
老版本debian ubuntu公钥过期修复与apt-key弃用后的判断
公钥过期和公钥缺失是两回事，过期通常表现为 KEYEXPIRED 或者 EXPKEYSIG，缺失才是 NO_PUBKEY，但两种问题的修复思路接近：拿到新 key，替换旧 key,或者直接移除已经不再使用的失效源。
目前不同导入方式的适用情况可以这样理解：
| 导入方式 | 推荐程度 | 适用版本 | 备注 |
|---|---|---|---|
apt-key adv --recv-keys |
临时可用 | Debian 10、Ubuntu 20.04 及更早 | 最简单，但写入全局信任，已弃用 |
gpg --dearmor 到 /usr/share/keyrings |
推荐 | Debian 11/12、Ubuntu 22.04/24.04 | 隔离干净，需配合 signed-by |
导出到 /etc/apt/trusted.gpg.d/ |
可以接受 |
全版本 | 比旧 apt-key 好管理，但仍是全局信任 |
| 直接删除失效第三方源 | 视情况 | 全版本 | 如果该源已经不用，删除最省事 |
处理老版本系统时，/etc/apt/trusted.gpg 被误删，可以重新安装系统自带的 keyring 包，Debian 下是 debian-archive-keyring，Ubuntu 下是 ubuntu-keyring：
sudo apt-get install --reinstall debian-archive-keyring
sudo apt-get install --reinstall ubuntu-keyring不过当前版本的公钥文件通常已经迁移到 /usr/share/keyrings/，旧位置的 trusted.gpg 只是兼容性残留。
多数情况下，W 警告不是系统损坏，而是某个仓库的信任关系断了，只要把 key 放回正确位置，apt update 就能恢复正常，对于国内服务器，优先从软件源官网直接下载 key 文件，比连公共 keyserver 更省时间，整件事折腾来回，本质就一句话：apt 只认你交给它的那串公钥，缺了哪个,补哪个。
Q&A：debian ubuntu没有公钥相关问题
Q：debian更新提示没有公钥怎么办会影响系统安全更新吗？
A：不会影响系统自带仓库的安全更新，apt 只是跳过缺少公钥的那个第三方源，deb.debian.org 或 archive.ubuntu.com 的更新仍然会正常进行，但如果缺少公钥的源里有 Nginx、Docker、Node.js 等你正在使用的软件，这部分安全补丁就拿不到,需要尽快补齐。
Q：ubuntu apt update 公钥缺失解决方法里 apt-key 还能用吗？
A：能用但不推荐。apt-key 在 Ubuntu 22.04 和 Debian 11 上仍然存在，执行后会警告已弃用，它会把 key 写入全局信任文件，时间长了容易弄不清楚哪个 key 对应哪个源，新装系统建议直接用 gpg --dearmor 把 key 放到 /usr/share/keyrings/，并在源文件里写 signed-by 路径。
Q：国内服务器 debian ubuntu 公钥导入一直失败是网络问题吗？
A：多数情况下是公共 keyserver 的连接问题，国内服务器访问 keyserver.ubuntu.com 经常超时，改用 hkp://keyserver.ubuntu.com:80 会好一些，更稳定的做法是直接从软件源官网下载 GPG key 文件，再导入到 /usr/share/keyrings/，如果软件源官网都连不上，说明网络链路本身就不适合该源,考虑换成国内镜像源。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/664629.html
