NO_PUBKEY错误表明APT缺少对应仓库的公钥，主因是换源后未同步密钥；应弃用apt-key，改用signed-by机制将密钥存入/usr/share/keyrings/并显式引用。
NO_PUBKEY 错误：系统压根没这个公钥
看到类似 NO_PUBKEY ED444FF07D8D0BF6 或 NO_PUBKEY 3B4FE6ACC0B21F32 的报错，说明 APT 根本没存对应仓库的公钥，常见于换源后直接改了 /etc/apt/sources.list 却没同步密钥。
别用 apt-key——它已被弃用，且会污染全局信任域。正确做法是把密钥单独存为 keyring 文件，并在源配置里显式引用：
- 先下载官方密钥（以 Kali 为例）：
wget https://archive.kali.org/archive-keyring.gpg - 存到标准位置：
sudo mv archive-keyring.gpg /usr/share/keyrings/kali-archive-keyring.gpg - 检查
/etc/apt/sources.list中对应行是否含signed-by=/usr/share/keyrings/kali-archive-keyring.gpg，例如：deb [arch=amd64 signed-by=/usr/share/keyrings/kali-archive-keyring.gpg] http://mirrors.aliyun.com/kali kali-rolling main contrib non-free non-free-firmware - 运行
sudo apt update验证
EXPKEYSIG 错误：密钥已过期
报错里出现 EXPKEYSIG 827C8569F2518CC677FECA1AED65462EC8D5E4C5 这类字符串，说明本地存的公钥有明确过期时间（比如 2025-04-01），现在已失效。这不是网络问题，是密钥生命周期到了。
必须更新密钥环包或重新导入最新密钥：
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- 优先尝试升级密钥环包：
sudo apt install --reinstall kali-archive-keyring（Kali）或sudo apt install --reinstall ubuntu-keyring（Ubuntu/Debian 衍生版） - 如果包不可用（如新版 Ubuntu 已移除
debian-archive-keyring），就手动导入：sudo gpg --dearmor -o /usr/share/keyrings/ubuntu-archive-keyring.gpg /tmp/ubuntu-keyring.asc，再确保源配置中signed-by指向该路径 - 验证密钥有效期：
gpg --list-keys --with-sig-list ED444FF07D8D0BF6 | grep "expires"，确认新密钥确实未过期
“The repository is not signed”：源配置漏了 signed-by
即使密钥文件已存在，只要 /etc/apt/sources.list 或 /etc/apt/sources.list.d/*.list 里没写 signed-by=...，APT 就会拒绝加载——这是 Debian 12+/Kali 2022.3+ 的强制要求，不是 bug。
注意几个易错点：
- 不能只写
[arch=amd64]，必须补全[arch=amd64 signed-by=/usr/share/keyrings/xxx.gpg] - 路径必须绝对且可读：
ls -l /usr/share/keyrings/kali-archive-keyring.gpg应返回权限为-rw-r--r-- - 如果用了镜像源（如阿里云、中科大），密钥仍是 Kali 官方的，不是镜像站自己的——别去搜“阿里云 kali gpg key”，那不存在
为什么不能用 AllowInsecureRepositories 临时绕过？
有些教程建议在 /etc/apt/apt.conf.d/70debconf 里加 Acquire::AllowInsecureRepositories "true";，这会让 APT 跳过所有签名检查。后果很直接：
- 中间人攻击下，你可能装上被篡改的
metasploit-framework或john，而自己毫无察觉 - 某些安全关键包（如内核、
openssl）更新会因签名缺失被静默跳过，留下漏洞 - Kali 的
checksec、gdb-peda等工具依赖精确版本，签名失效常伴随元数据损坏，导致后续apt install报依赖冲突
真正麻烦的从来不是密钥导入步骤，而是把 signed-by 写对、路径写对、权限写对——三者缺一，错误照旧。
