添加 VPN 软件源后 apt 更新报 NO_PUBKEY 失败

你的 VPN 厂商的 apt 软件源弄坏了包管理器，而修复方法是一个决定，而不是一条命令。NO_PUBKEY，或者提示软件源缺少 Release 文件，都意味着 apt 拒绝信任该源，于是之后每次包操作都会反复打印同一条警告。隧道本身多半是无辜的。只要回答三个问题——你是否还需要这个源——正确的修复几乎就会自动浮现。

第一步：把故障放进正确的分类

信任失败会指出源文件名，并指明是缺少密钥还是缺少 Release 文件。传输失败看起来完全不同：TLS 证书错误、连接被拒绝、超时，或者代理拒绝 CONNECT。这个区分决定了你该读哪篇文章，因为拦截 TLS 或封锁厂商主机的 VPN 产生的是传输错误，而不是签名错误。

先单独运行 sudo apt update，读取末尾几行，忽略上面那些缓存命中。真正关键的那一行会指出 /etc/apt/sources.list.d/，并告诉你该打开哪个文件。

如果故障出现在隧道建立之后，请在关闭隧道、并让 DNS 走系统解析器的情况下再测。不依赖 VPN 也能工作的源，属于路由或拦截问题，再怎么管理密钥也修不好。

三个问题决定走哪条路

你还会从这个源安装或升级包吗？如果客户端仍在实际使用，就修复信任。如果你只是装过一次客户端，现在往 NetworkManager 里导入一个普通配置文件，那这个源就是多余的负担，删掉才是诚实的修法。

第二，厂商是否公布了可以在带外核对的密钥与指纹？第三，这台主机上的密钥由谁管理：发行版，还是你自己？用一个你无法核对的密钥签名的源，等于把更新权限交给了一个不该给的对象。

第一个问题答“否”，分析就到此为止。三个问题都答“是”，就指向 signed-by 修复，因为这是唯一既可用又可审计的做法。把两条路混在一起——保留源、硬把它顶过去——是唯一值得明确排除的选项。

为什么 trusted=yes 看起来像修复，其实不是

《sources.list 手册页》对此说得很直接。把 Trusted 选项设为 yes，等于让 apt 即使认证失败也接受该源，这会关掉该软件源的 apt-secure。手册页只在本地场景下才保留这种用法，前提是确实要用。

这并不等于把对厂商的信任缩小一点。它直接删掉了“谁签署了索引”这个问题，于是任何能对那个主机名作出应答的一方，都能往你的机器里塞以 root 权限安装的包。

修复路线：先取密钥，再把它固定下来

从厂商文档给出的地址取得密钥，去除封装后放入由管理员管理的密钥环，然后把软件源那一行指向该文件，让信任无法漂移。

1. 读取报错那一行，取得密钥 ID 与源文件名。
2. 下载厂商的 ASCII 装甲密钥，并把 gpg --dearmor 执行到 /etc/apt/keyrings/vendor-name.gpg。
3. 把 [signed-by=/etc/apt/keyrings/vendor-name.gpg] 加到该厂商 .list 文件的条目里。
4. 运行 sudo apt update，确认该源能取到索引，而不是继续重复签名警告。

随软件包一起到来的密钥请放在 /usr/share/keyrings，手工放置的密钥请放在 /etc/apt/keyrings。这个区分不是装饰：它告诉下一位管理员哪些密钥能挺过包升级，哪些必须由人处理。

信任之前，先用厂商公布的值核对指纹。从论坛帖子粘贴来的密钥 ID，正是机器开始信任一个没人能说清名字的更新权限的方式。

移除路线，以及为什么错误可能回来

先看看安装脚本究竟写了什么，因为可能有多个文件提到同一个厂商，其中一个通常是残留副本。

grep -r . /etc/apt/sources.list.d/
sudo rm /etc/apt/sources.list.d/vendor.list

apt 只读取该目录下的 .list 和 .sources 文件，所以 .save 或 .distUpgrade 副本本来就被忽略；但顺手删掉它，可以避免后来的读者误把它恢复。移除源并不会卸载任何东西，apt 之后可能把已安装的 VPN 包描述为“本地安装”或“已不再可用”，那只是包状态提示，并不是信任错误又回来了。

反复出现的情形，是较早的教程用 apt-key 把密钥装进全局信任环。那条路已被弃用，而一次发行版升级就可能让密钥被丢弃或干脆没被查询，这也正是一个安静了一年的错误会恰好在升级那周冒出来的原因。检查 /etc/apt/trusted.gpg.d/，然后把信任决定挪到软件源那一行，那才是它该在的地方。如果厂商至今仍在打印 apt-key 指令，也请照样使用 signed-by；手册记录的就是这种做法，也是能挺过升级的那一种。