Ubuntu系统apt-offline离线安装包的安全校验方法

在物理隔离或网络受限的生产环境中，apt-offline 几乎是运维人员批量更新 Ubuntu 系统的唯一救命稻草。但很多人忽略了一个致命问题：你千辛万苦从联网机器上下载的 deb 包和更新索引，在通过 U 盘或移动硬盘倒手的过程中，是否被篡改过？是否因为存储介质故障而损坏？直接把这些未经验证的包喂给 apt-offline install，等同于在隔离系统上裸奔。安全校验不是可选项，而是离线部署流程中必须嵌入的关键环节。

离线安装包面临的风险可以拆解为两个层面。第一层是完整性风险，即文件在复制、传输、存储过程中发生比特翻转或意外损坏，这在劣质 U 盘或频繁插拔的场景下并不罕见。第二层是真实性风险，即包被恶意替换。假设你的联网下载机本身是干净的，但中间传递用的移动介质在别处被做了手脚，deb 包就可能被植入后门。apt-offline 本身只负责生成签名文件列表和安装，它并不自动校验每一个下载下来的 deb 包哈希值是否与官方仓库一致，这个责任需要你自己承担。

首先要纠正一个常见误解。apt-offline 在生成下载任务时，会创建一个名为 signature 的文件，里面记录了需要下载的所有文件的相对路径和 SHA256 校验和。这个 signature 文件本身可以用 GPG 签名，但这里的签名仅用于验证“下载任务列表”是否被篡改，也就是确保你拿着这个签名文件去联网机上下载时，下载的列表项没有被增删改。它并不验证你最终下载回来的 deb 包是否与 Ubuntu 官方仓库中的原始包一致。换句话说，apt-offline 的签名机制保护的是任务完整性，而非包源头真实性。

真正的安全校验必须从源头抓起。当你在联网机器上执行 apt-offline get 命令下载包时，apt-offline 会调用系统的 apt 工具从你配置的镜像源拉取 deb 包和对应的 Packages 索引文件。这个 Packages 文件是校验的核心，因为它包含了官方仓库中每个 deb 包的 SHA256、SHA512 甚至#更多校验值。关键操作是：在下载完成后，不要急着拔 U 盘，先在联网机上用 apt-offline 生成的 signature 文件与官方 Packages 索引进行交叉比对。你可以手动解析下载目录下的 Packages 或 Packages.gz 文件，提取其中每个包的 Filename、Size、SHA256 字段，然后逐个校验你下载的 deb 文件。

手动比对几百个包不现实，必须用脚本固化流程。下面这个脚本的思路是：在包含 deb 包和 Packages 索引文件的目录中运行，自动解析 Packages 文件，提取每个包的校验和，然后与实际文件进行比对。

#!/bin/bash
# 校验脚本：在下载目录中执行
# 依赖：bash, grep, awk, sha256sum

PACKAGES_FILE="Packages"  # 或 Packages.gz，需先解压
DEB_DIR="./"              # deb包存放目录
FAIL_COUNT=0

# 如果Packages是gz压缩格式，先解压
if [ -f "Packages.gz" ]; then
    gunzip -k Packages.gz
    PACKAGES_FILE="Packages"
fi

if [ ! -f "$PACKAGES_FILE" ]; then
    echo "错误：未找到 Packages 索引文件"
    exit 1
fi

# 逐包解析并校验
while IFS= read -r line; do
    if [[ $line == Filename:* ]]; then
        FILENAME=$(echo "$line" | awk '{print $2}' | xargs basename)
    fi
    if [[ $line == SHA256:* ]]; then
        EXPECTED_SHA=$(echo "$line" | awk '{print $2}')
        if [ -f "$DEB_DIR/$FILENAME" ]; then
            ACTUAL_SHA=$(sha256sum "$DEB_DIR/$FILENAME" | awk '{print $1}')
            if [ "$EXPECTED_SHA" != "$ACTUAL_SHA" ]; then
                echo "校验失败：$FILENAME"
                echo "  期望：$EXPECTED_SHA"
                echo "  实际：$ACTUAL_SHA"
                ((FAIL_COUNT++))
            else
                echo "校验通过：$FILENAME"
            fi
        else
            echo "文件缺失：$FILENAME"
            ((FAIL_COUNT++))
        fi
    fi
done < "$PACKAGES_FILE"

if [ $FAIL_COUNT -eq 0 ]; then
    echo "所有 deb 包校验通过，可安全用于离线安装。"
else
    echo "共发现 $FAIL_COUNT 个问题，请检查下载或存储介质。"
    exit 1
fi

将上述脚本保存为 verify_debs.sh，在下载目录中执行 bash verify_debs.sh。如果所有包都校验通过，说明从官方仓库到你下载机的这一段链路是干净的。这是你后续往离线环境传递的信任基础。

下载机上的包校验通过后，你需要把整个下载目录打包并安全地传递到离线机器。这里最大的风险是移动介质被篡改或感染。一个有效的防护手段是：在下载机上对整个下载目录生成一个带签名的哈希列表，然后在离线机器上验证这个列表后再执行安装。你可以使用 GPG 对文件列表进行签名，或者至少生成一个强校验文件并单独保管。

# 在下载机上生成整个下载目录的 SHA256 校验文件
cd /path/to/download/dir
find . -type f -exec sha256sum {} \; > ../offline_bundle.sha256

# 用 GPG 对校验文件进行签名（需要已有 GPG 密钥）
gpg --detach-sign --armor ../offline_bundle.sha256

将 offline_bundle.sha256 和它的签名文件 offline_bundle.sha256.asc 与下载包一起拷贝到移动介质。在离线机器上，先验证签名文件，再批量校验所有文件。

# 在离线机器上验证 GPG 签名
gpg --verify offline_bundle.sha256.asc offline_bundle.sha256

# 如果签名验证通过，再校验所有文件完整性
cd /path/to/offline/data
sha256sum -c ../offline_bundle.sha256 --quiet
if [ $? -eq 0 ]; then
    echo "传输完整性校验通过。"
else
    echo "文件损坏或被篡改，禁止安装！"
    exit 1
fi

这一步确保了从下载机到离线机的传输过程中，没有任何文件被修改、替换或损坏。如果 GPG 签名验证失败，或者 sha256sum 校验报错，绝对不能继续执行 apt-offline install。

即使传输校验通过，在正式安装前还有一项关键检查：验证 apt-offline 的 signature 文件是否与下载到的文件集一致。apt-offline install 命令在执行时会读取 signature 文件，确认所需文件是否齐全，但它默认只检查存在性，并不重新计算哈希。你需要在离线机器上手动用 signature 文件中的哈希值再校验一遍。signature 文件格式为每行包含“文件名 哈希值”，可以直接用 sha256sum 工具进行校验。

# 在离线机器上，进入包含 signature 和 deb 包的目录
cd /path/to/offline/data

# 提取 signature 中的哈希信息并校验
# signature 文件格式示例：pool/main/n/net-tools/net-tools_1.60+git20181103.0eebece-1ubuntu2_amd64.deb 8f3c2a1...
while IFS=' ' read -r fname fhash; do
    if [ -f "$fname" ]; then
        echo "$fhash  $fname" | sha256sum -c --quiet 2>/dev/null
        if [ $? -ne 0 ]; then
            echo "signature 校验失败：$fname"
        fi
    else
        echo "signature 中文件缺失：$fname"
    fi
done < signature

这一步是对 apt-offline 自身任务完整性的二次确认，防止 signature 文件在移动介质上被悄无声息地修改#修改。

很多人在离线更新时只关注 deb 包，却忽略了 Packages 索引文件本身的安全。Packages 文件是 apt 判断包版本、依赖关系和校验和的唯一依据。如果这个文件被篡改，攻击者可以诱导系统安装旧版本有漏洞的包，或者绕过哈希校验。在联网机上下载 Packages 文件时，务必确保其来源是官方镜像且通过 HTTPS 或 GPG 签名验证。Ubuntu 的官方镜像通常提供 InRelease 或 Release.gpg 文件用于验证 Packages 索引的完整性。你可以在联网机上用 apt 自动下载的 /var/lib/apt/lists/ 下的 InRelease 文件来验证，但离线场景下，更实际的做法是：在下载时同时拉取 Release 和 Release.gpg 文件，然后在离线机器上用 Ubuntu 官方公钥验证。

# 在联网机上，下载 Release 和 Release.gpg
wget http://archive.ubutu.com/ubutu/dists/focal/Release
wget http://archive.ubutu.com/ubutu/dists/focal/Release.gpg

# 在离线机器上导入 Ubunt 官方公钥并验证
gpg --keyserver hkp://keyserver.ubutu.com --recv-keys 3B4FE6ACC0B21F32
gpg --verify Release.gpg Release

如果验证通过，说明 Packages 索引文件可以被信任，进而用其内部的哈希值校验 deb 包。这一链条形成了从官方仓库到离线安装的完整信任链。

对于需要频繁进行离线更新的生产环境，建议将上述校验步骤集成为一个自动化脚本，在 apt-offline install 之前强制运行。脚本逻辑应包括：验证 GPG 签名、校验传输文件完整性、用 Packages 索引校验 deb 包、用 signature 文件校验任务完整性。任何一步失败都中止安装并告警。这样的流程虽然增加了离线更新的时间成本，但在等保合规或金融、能源等关键基础设施场景中，这是必须的安全基线。

误区一：认为 apt-offline 会自动校验包哈希。实际上 apt-offline 在安装时调用的是 dpkg -i，而 dpkg 本身不校验包来源哈希，它只校验包内的 md5sums 文件（如果存在的话），但那只能验证包安装后文件的完整性，不能验证包本身的来源真实性。误区二：用 md5 或 SHA1 校验 deb 包。Ubuntu 官方 Packages 索引中提供的哈希至少是 SHA256 起，使用弱哈希算法无法抵抗碰撞攻击。误区三：在离线机器上首次安装 apt-offline 时，直接从移动介质拷贝 deb 包安装，却不校验这个 deb 包本身。这可能导致 apt-offline 工具本身被篡改，后续所有校验形同虚设。正确做法是：在联网机上用官方源下载 apt-offline 的 deb 包，并验证其 GPG 签名或至少用官方提供的 SHA256 值校验后，再拷贝到离线机安装。

离线环境下的包管理安全，本质上是建立一条从官方仓库到目标机器的可信链路，并在每一个传输节点上设置校验关卡。apt-offline 只解决了“传”的问题，而“验”的责任必须由运维者自己承担。把上述校验方法固化到 SOP 中，才能确保隔离网络中的 Ubuntu 系统不被供应链攻击击穿。