### [VPS执行apt update报NO_PUBKEY或EXPKEYSIG怎么办？先定位软件源，别绕过签名](https://www.jiyueip.com/article/13322)

**Published:** 2026-07-29T18:04:12

**Author:** 斑斓助理

**Excerpt:** VPS运行apt update出现NO_PUBKEY、EXPKEYSIG或仓库未签名时，应先确认出错的软件源、系统时间和密钥来源，再按仓库官方说明使用独立keyring与Signed-By修复。

VPS执行`apt update`出现`NO_PUBKEY`、`EXPKEYSIG`、`The following signatures were invalid`或“仓库没有Release签名”，说明APT无法按当前信任配置验证仓库元数据。它不是普通下载超时，也不应通过关闭签名检查来“修好”。

**先找到具体失败的软件源和密钥标识，再检查系统时间、仓库状态与密钥配置。**只有确认仓库身份和官方更新方式后，才替换密钥或修改`Signed-By`。随意从搜索结果导入公钥，可能把错误密钥加入系统信任。

## 先读懂几类常见报错

| 提示  | 通常说明什么 | 优先检查 |
| --- | --- | --- |
| NO\_PUBKEY | 缺少验证当前签名所需的公钥，或软件源没有引用正确keyring | 仓库URL、密钥指纹、Signed-By路径 |
| EXPKEYSIG | 签名或用于签名的密钥有效性出现问题 | 系统时间、仓库公告、新密钥与新Release |
| Release file is not valid yet | 本机时间可能落后，或镜像元数据时间异常 | 时区、NTP和当前UTC时间 |
| repository is not signed | 仓库缺少APT可验证的签名信息 | URL是否正确、发行版代号、仓库是否已停用 |
| does not have a Release file | 路径、发行版版本或仓库结构不匹配 | sources配置和仓库支持列表 |

一条`apt update`可能同时访问系统官方仓库、Docker、数据库、监控工具和其他第三方源。只要其中一个失败，就应针对那一个源处理，不要删除全部密钥或重写所有源。

## 第一步：保存完整错误并定位软件源

```
sudo apt-get update
```

记录报错中的仓库域名、发行版代号、密钥指纹或ID以及错误类型。再检查当前软件源：

```
grep -R --line-number -E '^(deb |deb-src |Types:|URIs:|Suites:|Signed-By:)' 
  /etc/apt/sources.list /etc/apt/sources.list.d 2>/dev/null
```

Debian传统单行源通常使用`.list`，deb822格式通常使用`.sources`。不要看到同一域名出现多次就立即删除；先判断是否分别提供二进制包、源码包或不同组件。

## 第二步：检查VPS时间是否可信

```
date -u
timedatectl status
```

时间偏差会影响签名和Release文件有效期判断。若时间明显错误，先核对云平台时钟、NTP或chrony状态，再重新运行更新。只为了通过签名检查手工把时间调到任意日期，会让TLS、日志和定时任务出现新的问题。

如果VPS既无法解析仓库域名又报连接错误，应先按[VPS DNS解析链与53端口排查](https://www.jiyueip.com/article/13258)恢复名称解析，再判断剩余签名错误。

## 第三步：确认仓库仍支持当前系统版本

-   检查系统发行版和代号是否与软件源一致；
-   查看仓库官方文档是否更换域名、组件或安装方式；
-   确认旧版本系统是否已经停止提供该仓库；
-   检查代理、缓存镜像或企业内网镜像是否仍同步最新Release；
-   不要把另一个Ubuntu或Debian版本的源直接套到当前系统。

若只有第三方仓库失败，可以先在维护窗口暂时禁用该源并重新更新系统官方仓库，但这不等于问题已经修复。依赖该仓库的软件将暂时无法获得更新，应记录并安排后续处理。

## 第四步：按官方渠道更新专用keyring

`apt-key`已经弃用。对第三方仓库，更清晰的做法是将经过核对的仓库公钥保存在专用keyring中，并让该软件源通过`Signed-By`只信任这一组密钥。

```
sudo install -m 0755 -d /etc/apt/keyrings
ls -l /etc/apt/keyrings /usr/share/keyrings
```

具体密钥下载地址、文件格式和指纹必须以仓库当前官方文档为准。获取密钥时使用可信通信渠道，核对域名、TLS和官方公布的指纹。不要把文章中的示例域名、论坛附件或陌生代码仓库当作密钥来源。

传统`.list`源通常类似：

```
deb [signed-by=/etc/apt/keyrings/vendor.gpg] 仓库官方HTTPS地址 stable main
```

deb822格式通常把路径放在独立字段：

```
Types: deb
URIs: 仓库官方HTTPS地址
Suites: stable
Components: main
Signed-By: /etc/apt/keyrings/vendor.gpg
```

以上只说明结构，不是可直接使用的软件源。`Signed-By`的价值是限制某个仓库使用指定密钥验证，避免把所有第三方密钥放进全局信任范围。

## 不要用这些方式掩盖问题

-   为互联网仓库添加`trusted=yes`；
-   设置`allow-insecure=yes`或全局允许不安全仓库；
-   长期使用`--allow-unauthenticated`安装软件包；
-   从未知钥匙服务器按短ID盲目导入密钥；
-   把第三方密钥加入全局trusted.gpg而不限制仓库；
-   删除全部keyring后反复尝试更新。

APT的Release签名用于确认仓库元数据没有被不持有签名密钥的人修改。绕过认证可能让更新“继续运行”，却失去判断包索引是否可信的基础。

## 修复后怎样验收

1.  重新运行`sudo apt-get update`并保存完整输出；
2.  确认原仓库不再出现NO\_PUBKEY、EXPKEYSIG或未签名警告；
3.  检查没有因编辑错误而忽略其他`.list`或`.sources`文件；
4.  确认keyring文件可被`_apt`读取，Signed-By路径正确；
5.  使用`apt-cache policy`核对候选包来自预期仓库；
6.  保留旧配置备份和变更记录，出现异常时可回滚。

如果问题实际是下载超时、代理或连接速度，而签名验证已经正常，应转到[npm、pip与APT网络代理配置](https://www.jiyueip.com/article/12793)处理连接路径，不要继续修改密钥。

## 结论

VPS的APT签名错误应按“失败仓库、系统时间、版本支持、官方密钥、Signed-By、更新复验”处理。NO\_PUBKEY不是让用户关闭验证的提示，EXPKEYSIG也不能只靠重新导入任意密钥解决。确认仓库身份并缩小信任范围，才是比绕过签名更安全、可维护的修复。

**Tags:** Linux服务器, Ubuntu服务器, VPS, 云服务器, 企业网络合规

**Categories:** 行业洞察

---