Linux软件源签名报错与foremost无法定位的完整修复指南

最近好几个做数据恢复和渗透测试的朋友跟我聊到同一个问题：想在Linux上装foremost这个取证工具，结果第一步sudo apt-get update就栽了——屏幕上冒出“没有数字签名”的报错，好不容易查了一堆资料，换了阿里云源再试，反而又跳“无法定位软件包foremost”。这个组合报错非常典型，我在帮人排查时遇到过不下十次。今天把这个问题拆开讲明白，说清楚两个报错各自的来龙去脉，以及一套能直接抄作业的修复流程。文章适合刚接触Linux软件源管理的新手，也适合被这个报错卡住的取证工具使用者。

1. 两个报错，两种病因——先别急着乱试

很多人一看到报错就开始无脑执行网上的“万能命令”，比如apt-get update、apt-get upgrade、换源、清缓存，试了一圈发现还是老样子。原因很简单：你遇到的根本不是一个问题，而是两个问题叠在一起了。apt-get update报“没有数字签名”和apt install foremost报“无法定位软件包”，这两件事的病因完全不同，解决顺序也有讲究，必须先处理签名，再处理软件源。

1.1 “没有数字签名”到底在说什么

执行sudo apt-get update时，系统会去指定的软件源下载一个叫Release的文件，这个文件相当于整个软件库的“目录清单”。为了保证这份清单没有被篡改，源服务器会在清单上附加数字签名。apt在拿到文件后，要用本机已经保存的公钥去校验这个签名。如果校验不通过，apt会拒绝信任这个源，并输出类似这样的提示：

bash复制W: GPG error: http://mirrors.aliyun.com/ubuntu/dists/jammy/InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 871920D1991BC93C
E: The repository 'http://mirrors.aliyun.com/ubuntu/dists/jammy/InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.

这里的重点有两个。一是NO_PUBKEY加一串十六进制字符，它告诉你“系统里缺少这把公钥”；二是后面那句is not signed，它其实是公钥缺失导致的最终结果，并不是这个源真的没有签名。换句话说，你看到的“没有数字签名”，大多数时候是“没有数字签名对应的公钥”，而不是“这个源没做签名”。

还有一种情况也值得注意：如果系统时间差得太远，公钥的有效期校验会失败，同样会报签名错误。这一点后面细讲，但它绝对是排查时最容易忽略的坑。

1.2 “无法定位软件包”又是另一码事

apt install foremost提示Unable to locate package foremost，意思是：apt在已经获取到的软件包列表里，根本找不到叫foremost的包。这个和签名问题没有直接关系，即使所有签名都正常，只要软件源里没有这个包，或者源里包含该包的组件没有被启用，你就永远装不上。

所以这里的关键问题变成了：foremost到底在哪个软件源里？你的系统到底有没有把这个源配置进去？很多人换了阿里云源还是不行，大概率就栽在这个环节。

1.3 为什么“换了阿里云源”还是不行

换源本身是个正确思路，但实际操作中，换源失败最常见的原因是“只换了地址，没换对配置”。举个例子，你在网上复制了一段阿里云的Ubuntu源模板，里面写的是noble（24.04的代号），但你系统实际是jammy（22.04），apt去请求一个不存在的目录，自然要么404，要么拿不到有效签名。

另一个更隐蔽的问题是，很多精简版的Ubuntu源模板只启用了main组件，而foremost这个包在Ubuntu里放在universe组件下。你就算把源地址换成阿里云，组件没启用，照样无法定位。再有一种情况是系统其实不是Ubuntu，而是基于Debian的Kali或其他发行版，却复制了Ubuntu的源地址，那结果必定是鸡飞狗跳。

所以，换源不是目的，把源配置成“符合你系统版本、包含需要的组件、且签名完整”才是目的。

2. 数字签名问题：从原理到实操一次搞定

既然要先解决数字签名问题，那就把GPG签名这套机制的关键点讲透，然后给出一套可以落地的操作流程。理解了原理之后，以后再遇到五花八门的签名报错，自己就能判断该怎么处理。

2.1 apt为什么对签名这么较真

你可以把软件源理解成一个公共仓库，任何人都能在里面放东西。为了保证你下载的软件包确实来自仓库管理员，而不是某个中间人篡改过的版本，apt引入了GPG签名机制。仓库管理员用私钥给Release文件签名，你的系统里存有对应的公钥，每次update时用公钥验签。验签通过，说明这份文件确实是管理员发布的，内容没有被改过；验签失败，apt宁可报错也不冒险使用这个源。

这个逻辑和银行快递的道理类似：你收到一封贴着防伪封条的快递，只有确认封条是真的才敢拆开。apt看到签名不完整，第一反应就是“这可能是个假快递”，然后拒绝更新。

2.2 定位缺失的公钥ID

处理签名问题，第一步不是瞎导入公钥，而是先看清楚系统到底缺哪把公钥。执行更新命令时，把输出仔细看一遍，找到NO_PUBKEY后面的那串字符，那就是缺失公钥的ID：

bash复制sudo apt-get update 2>&1 | grep NO_PUBKEY

输出会类似这样：

bash复制NO_PUBKEY 871920D1991BC93C
NO_PUBKEY 3B4FE6ACC0B21F32

拿到这串ID后，先去确认它属于哪个源。大多数情况下，这个ID对应的是Ubuntu官方密钥、Kali官方密钥，或者你添加的某个第三方软件的密钥。比如871920D1991BC93C是Ubuntu 22.04的Archive自动签名密钥，很多人在换源后遇到的就是它。

2.3 导入公钥的三种实用方式

第一种，也是最推荐的方式，是直接从发行版官方获取经过打包的keyring软件包。Ubuntu用户可以直接重装密钥包：

bash复制sudo apt install ubuntu-keyring --reinstall

Kali用户则可以下载官方存档密钥并导入：

bash复制wget -qO- https://archive.kali.org/archive-key.asc | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/kali-archive-keyring.gpg

第二种方式，从GPG公钥服务器在线获取。适用于你明确知道缺失的Key ID，且该公钥确实发布在公钥服务器上的场景：

bash复制sudo gpg --keyserver keyserver.ubuntu.com --recv-keys 871920D1991BC93C
sudo gpg --armor --export 871920D1991BC93C | sudo tee /etc/apt/trusted.gpg.d/custom.gpg > /dev/null

第三种方式，直接在/etc/apt/sources.list.d/里面通过signed-by参数指定公钥文件。这种方式最干净，适合有多个源的场景，不会污染全局信任列表。要注意的是，signed-by只接受二进制格式的公钥文件，所以需要先用gpg --dearmor把asc格式转成gpg格式。

2.4 公钥导入后的正确验证步骤

导入完成后别急着安装软件，先重新执行一次更新，确认签名报错消失：

bash复制sudo apt-get update

正常情况下，此时会看到Hit、Get之类的正常日志，不再有NO_PUBKEY和is not signed。如果还报错，先检查系统时间：执行date看当前时间，再用timedatectl set-ntp true开启自动时间同步，等两三分钟再试。时间不同步导致签名“过期”或“未生效”的情况，我至少见过五六次，明明密钥没问题，就是时间戳对不上。

提示：如果有一个第三方源始终无法通过签名验证，而且你确实不需要它，最省事的办法是注释掉对应的源行，而不是强行禁用它。强行禁用虽然能让update不再报错，但以后想用这个源时容易忘记。

3. “无法定位软件包”：先弄清foremost在哪里

签名问题解决后，再回头看“无法定位软件包foremost”。很多人到这里就以为只要重新apt-get update就能装上，结果还是失败。原因在于，foremost这个包并不在所有发行版的默认源里都存在。你需要先弄明白自己系统的情况，再决定怎么配置源。

3.1 确认你的发行版和版本

这一步极其关键，但也是很多人跳过的。要想知道该配哪个源，先得知道自己是哪个系统、哪个版本。执行：

bash复制cat /etc/os-release

输出里会明确写清楚发行版名称和版本代号。比如Ubuntu 22.04的代号是jammy，Ubuntu 24.04是noble，Debian 12是bookworm，Kali则是滚动发行版，没有固定版本号。

另一个常用命令是lsb_release -a，但部分精简系统没装lsb_release，所以cat /etc/os-release更通用。同时用uname -m确认架构，一般是x86_64。搞清楚这些，再去写源配置，才能保证地址正确。

3.2 检查sources.list到底写了什么

软件源配置集中在/etc/apt/sources.list和/etc/apt/sources.list.d/目录下的文件里。如果你系统里既有主配置文件，又有目录下的额外配置，apt会合并读取它们。建议先看一遍：

bash复制cat /etc/apt/sources.list
ls /etc/apt/sources.list.d/

正常的Debian系源行格式是：

bash复制deb 地址 版本代号 组件1 组件2 组件3

其中deb表示二进制软件包来源；版本代号就是jammy、noble、kali-rolling这类；组件则是main、universe、restricted、multiverse。Ubuntu官方源默认包含这四个组件，但很多第三方教程模板会故意精简成只有main，这就是foremost找不到的常见原因。

3.3 foremost在不同发行版里的藏身处

• Kali Linux：默认可用的源里就包含foremost，不需要额外操作。如果你在Kali里提示无法定位，基本可以断定是源配置出了问题，或者把源写成了Ubuntu的。
• Ubuntu：foremost位于universe组件中。只要你的源配置启用了universe，并成功执行过apt-get update，就能正常安装。很多人换源时只保留main，那当然找不到。
• Debian：foremost在官方仓库中属于main组件，常规安装一般没问题。

所以结论很明确：用Ubuntu系统遇到无法定位，优先检查是否启用了universe组件；用Kali系统遇到无法定位，优先检查源地址是否写成了Kali自己的源，而不是Ubuntu的源。

3.4 添加软件源并安装的实际操作

以Ubuntu 22.04使用阿里云镜像为例，完整的/etc/apt/sources.list可以写成这样：

bash复制deb http://mirrors.aliyun.com/ubuntu/ jammy main restricted universe multiverse
deb http://mirrors.aliyun.com/ubuntu/ jammy-updates main restricted universe multiverse
deb http://mirrors.aliyun.com/ubuntu/ jammy-security main restricted universe multiverse
deb http://mirrors.aliyun.com/ubuntu/ jammy-backports main restricted universe multiverse

注意每一行末尾都要带上universe。如果你用的是Ubuntu 24.04，把jammy换成noble，其他保持不变。配置完成后执行：

bash复制sudo apt-get update
sudo apt-get install foremost

如果一切正常，foremost会安装到/usr/bin下，用foremost -h可以看到帮助信息，说明安装成功。

4. 一份可直接照抄的完整修复流程

为了让你少走弯路，我把上面所有操作串成一个完整的流程。这个流程我在多台Ubuntu和Kali机器上实测过，照着操作基本都能解决问题。唯一要提醒的是，全程需要root权限，建议所有命令前都加sudo。

4.1 备份并重建sources.list

动手改文件之前，先备份，这是所有服务器操作的基本习惯：

bash复制sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak.$(date +%F)

备份文件名里带日期，方便以后回滚。然后用编辑器打开主源文件，或者直接写新文件。Ubuntu 22.04的阿里云源模板如下：

bash复制sudo tee /etc/apt/sources.list > /dev/null << 'EOF'
deb http://mirrors.aliyun.com/ubuntu/ jammy main restricted universe multiverse
deb http://mirrors.aliyun.com/ubuntu/ jammy-updates main restricted universe multiverse
deb http://mirrors.aliyun.com/ubuntu/ jammy-security main restricted universe multiverse
deb http://mirrors.aliyun.com/ubuntu/ jammy-backports main restricted universe multiverse
EOF

如果你用的是Kali，源模板则是：

bash复制sudo tee /etc/apt/sources.list > /dev/null << 'EOF'
deb https://mirrors.aliyun.com/kali kali-rolling main non-free contrib
EOF

这里要注意，Kali的源必须用https协议，否则会请求不到。而且Kali源不要添加deb-src行，除非你确实需要源码包。

4.2 按顺序处理签名和更新

源改好后，先别急着install。第一步，重装或导入密钥。Ubuntu用户执行：

bash复制sudo apt install ubuntu-keyring --reinstall

Kali用户下载并导入官方密钥。然后执行更新：

bash复制sudo apt-get update

这一步必须确认没有任何签名报错。如果还有NO_PUBKEY，用前面第2章的方法定位并导入。只有update完全不报错，后面安装才能顺利进行。如果在apt-get update过程中看到404 Not Found，多半是版本代号写错了，立刻检查sources.list。

4.3 安装foremost并验证

更新通过后，直接安装：

bash复制sudo apt-get install foremost -y

安装完成后，验证一下可执行文件是否真的可用：

bash复制which foremost
foremost -h

which能找到路径，foremost -h能输出帮助信息，就说明安装到位了。如果在安装过程中提示“软件包没有可安装候选”，先回到第4.2步确认update是否成功，再确认universe组件是否在源行中。

提示：如果你是在一台离线机器上部署，没法用apt安装，可以到packages.ubuntu.com搜索foremost，下载对应架构的deb包，然后用sudo dpkg -i foremost_*.deb安装。foremost的依赖很少，这种方案在离线环境下很实用。

5. 常见问题与避坑记录

操作过程中踩坑是难免的。我把这几年帮人排查这类问题的高频场景整理成一个速查表，再分享几条用教训换来的经验。

5.1 高频问题速查表

5.2 几条我用教训换来的经验

第一，Kali和Ubuntu的源绝对不能混用。Kali是基于Debian的滚动发行版，它的软件版本和依赖和Ubuntu差异很大。有人图省事直接把Ubuntu的阿里云源写到Kali里，然后整个系统依赖直接崩掉。要装Kali的取证工具，就用Kali自己的源，官方源慢的话就换阿里云的Kali镜像。

第二，apt-key add这个命令在新版系统中已经标记为废弃，很多新教程还让它导入公钥，导致系统刷出大量警告。正确的做法是把公钥转成.gpg文件放到/etc/apt/trusted.gpg.d/目录，或者在源配置里用signed-by=精确指定，这样既安全又不影响后续操作。

第三，不要一看到签名报错就去删除/var/lib/apt/lists目录里的缓存。这个操作解决不了签名问题，只会让你下次update时重新下载全部索引，白白浪费时间。处理签名的正确思路永远是：先确认缺哪个公钥，再导入对应公钥，最后重新update验证，二不要盲目清缓存换源。

第四，系统时间是所有签名验证的基础。我遇到过一台内网机器，因为CMOS电池没电，时间停留在两年前，结果每次apt操作都报签名过期。换源、导公钥都没用，最后把时间同步过来，问题瞬间消失。所以如果你排查了一圈还是签名错误，务必先看一眼系统时间。

第五，如果你只是为了用foremost做一次数据恢复或取证分析，不一定非要把它装到系统里。可以找一台临时的Ubuntu虚拟机，配置好源之后apt-get install foremost，然后把目标磁盘以只读方式挂载进去，用foremost直接提取文件。这样既不影响你的主力系统，也避免了乱改源带来的风险。

写在最后

我自己被这套组合报错折磨过几次之后，养成了一个习惯：遇到apt问题，先分清楚是“源的问题”还是“包的问题”。签名报错大部分是源的问题，无法定位包大部分是源配置不完整的问题。把这两个维度分开排查，比盲目执行网上一堆命令要高效得多。如果你按上面的流程操作，签名问题解决后重新update，再安装foremost，基本就能顺利跑通。万一过程中还有别的报错，把完整输出复制下来，对照速查表逐项排查，大概率能定位到原因。