GPG 密钥过期
起源
使用apt install的时候发现镜像部分出现报错
1 | Err:3 https://mirrors.tuna.tsinghua.edu.cn/kali kali-rolling InRelease |
检查发现是GPG密钥过期
AI诊断:
Kali Linux 软件源签名密钥过期 和 部分镜像站同步问题,
GPG签名失效(什么是GPG密钥)：所有镜像站（阿里云/清华/中科大）均报告
EXPKEYSIG ED444FF07D8D0BF6错误，表示Kali官方密钥已过期。
报告apt-key弃用
添加GPG密钥对时候发现报错apt-key add archive-key.asc
1 | Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)). |
apt-key已经弃用了,因为直接改会影响全局
全局信任（全盘授权）
使用 apt-key add 添加的密钥，会被所有仓库源信任，无论是官方的，还是第三方的。这带来两个问题：
- 如果你添加了一个第三方仓库的公钥，它可以伪造任何仓库的软件包签名，甚至冒充 Kali 官方！
- 一旦这个第三方密钥被泄漏或滥用，就存在被下毒包“钓鱼”的可能。
就像你把你家钥匙给了一个人，然后这把钥匙还能开你办公室、保险柜和你朋友家门……
不够精细化
现代 APT(trusted.gpg.d) 支持 signed-by=/路径/到/某个key.gpg，可以精确指定某个仓库只使用某个密钥进行验证，更安全、可控。
使用trusted.gpg.d管理(传统方式)
这样只在 /etc/apt/trusted.gpg.d 中以文件方式管理密钥，不用污染全局，每个源都可以绑定自己的签名公钥。
手动导入密钥
下载并添加 Kali 的 GPG 密钥
1 | curl -fsSL https://archive.kali.org/archive-key.asc | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/kali-archive.gpg |
1 | sudo apt update |
在这个文件夹中保存了对应的密钥文件,每个源按需绑定,也可以直接删除对应的文件
如果发现对应的密钥下载错了,也可以删除
1 | sudo rm /etc/apt/trusted.gpg.d/kali-archive.gpgrr |
检查导入的密钥是否生效
1 | gpg --show-keys /etc/apt/trusted.gpg.d/kali-archive.gpg |
但是实际上这样的管理方式并不安全,甚至有点混乱,与之对应的是. 在 source 中声明 signed-by的显式声明密钥绑定
按照报错来导入密钥
出现了这样的密钥,直接指明NO_PUBKEY ED444FF07D8D0BF6
1 | sudo gpg --keyserver keyserver.ubuntu.com --recv-keys ED444FF07D8D0BF6 |
Ubuntu是对的,只是一个公钥分发机构,👉
keyserver.ubuntu.com是 Ubuntu 社区维护的一个 公共 GPG 密钥服务器，不是只用于 Ubuntu，Kali、Debian、Arch 等系统都可以从这里拉取 GPG 公钥。
自动进行密钥管理(现代)
可以手动编辑/etc/apt/source.list,直接指定signed-by=
1 | deb [signed-by=/usr/share/keyrings/kali-archive-keyring.gpg] https://http.kali.org/kali kali-rolling main non-free non-free-firmware |
不需要手动下载密钥，推荐官方方式：
1 | sudo apt install --reinstall kali-archive-keyring |
这个 .deb 安装包会：
- 安装
.gpg文件到/usr/share/keyrings/ - 正确设置 source 里的
signed-by= - 避免手动失误
换源
源路径 /etc/apt/sources.list.d/文件夹以及/etc/apt/sources.list
文件里面是默认的源的路径(保存在一个文件中),文件夹中的源是拓展的源,在这个文件夹中,一个源存在一个路径
kali官方源
1 | # 官方软件源，使用 https 和新版 non-free-firmware 组件 |
✅ 加入 non-free-firmware：Kali 官方已将一些固件包从 non-free 移到 non-free-firmware，否则可能找不到驱动或固件。
✅ 这个官方源会自动跳转的CDN,但是实际上仍然是官方源. 访问这个地址时，实际上会被 302/HTTP 重定向到一个地理上距离你最近的镜像站点，比如：
mirror.twds.com.tw（台湾）mirror.nju.edu.cn（南京大学）mirrors.ocf.berkeley.edu（美国）Kali 官方维护的全球镜像网络（在 官方镜像列表 中都有）。
追加新源（保留原有内容）
1 | echo "deb https://mirrors.tuna.tsinghua.edu.cn/kali kali-rolling main non-free contrib" | sudo tee -a /etc/apt/sources.list |
注：-a 参数表示追加（append），不加则会覆盖原文件。
对比其他写法
| 方法 | 示例 | 缺点 |
|---|---|---|
| 直接重定向 | sudo echo "内容" > 文件 |
重定向部分权限不足 |
使用 tee |
echo “内容” | sudo tee 文件 |
| 文本编辑器 | sudo nano 文件 |
需要交互操作 |
什么是GPG密钥
GPG密钥在此处的应用原理
理解过程
APT 在更新软件包索引时，会校验这些索引是否由官方签名。如果缺少 GPG 公钥，它就没法验证签名的合法性，因此就会报这个错误，并跳过这个源的更新。
apt/apt-get安装之间需要校验软件包,只有通过约定好的私钥加密的软件包才能被本地的公钥解密通过验证(校验索引)才能进行下载. 而这一套验证的公私钥又会定期更换,所以因为长时间没有更换公钥导致这个无法解密而导致下载失败
APT的软件包验证机制
APT的验证流程分为两个层级：
- 元数据验证
- 软件源提供的
InRelease或Release.gpg文件包含仓库元数据的GPG签名（如软件包列表的哈希值）。 - APT会用本地存储的发行版公钥如
ED444FF07D8D0BF6验证这些签名，确保元数据未被篡改
- 软件源提供的
- 软件包完整性验证
- 每个软件包（
.deb文件）的哈希值记录在元数据中，APT下载后会比对哈希值，确保文件完整 - 但软件包本身并未用私钥加密，而是通过哈希值+元数据签名实现防篡改。
- 每个软件包（
密钥更新的必要性
密钥过期问题：
Kali等发行版的公钥有有效期（如报错中出现的
expired: 2025-01-24）。若未及时更新公钥，APT无法验证新签名的元数据，导致下载失败. 对于过期密钥, APT发现密钥过期会直接拒绝下载软件密钥轮换逻辑：发行版会定期更换密钥对（如每2年），旧密钥过期前会通过官方渠道发布新密钥。用户需手动或自动更新公钥链
都是非对称加密, 和tls的区别
PG密钥和TLS证书的签发机制在核心原理上相似（均基于非对称加密和数字签名），但在具体实现和应用场景上有显著差异：
核心相似性
- 非对称加密基础：两者均使用公钥/私钥对（如RSA/ECC算法）实现加密和签名
- 数字签名验证：均通过签名验证数据完整性和身份真实性（如GPG签名文件、TLS验证服务器证书）
关键差异
| 特性 | GPG密钥 | TLS证书 |
|---|---|---|
| 信任模型 | 分布式信任（Web of Trust） | 中心化信任（CA机构） |
| 签发主体 | 用户自签或互签 | 权威证书颁发机构（CA） |
| 主要用途 | 文件/邮件加密、代码签名 | 网站身份验证、加密通信（HTTPS） |
| 证书格式 | OpenPGP标准 | X.509标准 |
| 密钥管理 | 用户自主管理（如gpg --gen-key） |
CA统一签发和管理 |
典型流程对比
- GPG签名：用户A用私钥签名文件 → 用户B用A的公钥验证签名
- TLS证书验证：服务器发送CA签名的证书 → 客户端用CA公钥验证证书链
应用场景
- GPG：适合个人或小范围安全通信（如Linux软件包签名）
- TLS：适用于大规模互联网服务（如银行网站、电商平台）
总结
两者均依赖非对称加密，但GPG强调去中心化信任，TLS依赖CA体系。若需验证网站身份，必须使用TLS证书；若需个人数据加密或签名，GPG更灵活
