journalctl --verify 是验证已密封日志完整性的离线校验工具，需先启用forward secure sealing（配置storage=persistent、seal=yes、keyedhash=yes，运行--setup-keys并重启服务），校验通过仅表明自密封起未被篡改，依赖密钥与目录权限严格保护。

journalctl --verify 不是日志“防篡改”的开关，而是验证已密封日志是否被改动的校验工具。它只在 Forward Secure Sealing（前向安全密封）启用后才真正有效——否则仅检查文件格式，无法发现内容篡改。

确认密封机制已就位

密封是校验有效的前提，缺一不可： - 编辑 `/etc/systemd/journald.conf`，确保包含且未注释以下三行：

[Journal]
Storage=persistent
Seal=yes
KeyedHash=yes

- 运行 `journalctl --setup-keys` 生成密钥（自动存于 `/var/log/journal//.journal-secrets`，权限为 `600`） - 重启服务：`systemctl restart systemd-journald` - 验证是否生效：`journalctl --header | grep SEALED` 应输出 `HEADER_COMPATIBLE_SEALED: yes`

执行完整性校验

校验过程完全离线，不修改日志，依赖哈希链与 TAG 对象： - 扫描全部持久化日志：`journalctl --verify` - 验证某次启动日志：`journalctl -b -1 --verify` - 检查指定目录：`journalctl -D /var/log/journal/ --verify` - 校验单个文件：`journalctl --file /var/log/journal/xxx.journal --verify` - 加 `-v` 或 `--verbose` 查看每步计算细节；静默模式下返回状态码：0（PASS）、1（FAIL）、2（无密封信息）

读懂验证结果

- 正常输出形如：`PASS: /var/log/journal/abc123/system.journal` - 若日志被修改（如用 hexedit 编辑），会明确提示 `FAIL: hash chain broken at entry XXXX`，并指出损坏位置和时间点 - PASS 仅表示“当前磁盘上的该日志块自首次密封起未被改动”，不代表全程可信——密钥文件权限（`600 root:root`）和日志目录权限（`750 root:systemd-journal`）必须严格保护

日常运维建议

- 将 `journalctl --verify` 纳入定期审计脚本（例如每日凌晨执行并记录结果） - 避免系统时间大幅回拨，否则影响 TAG 时间戳连续性，削弱密封效力；建议启用 NTP 同步 - 日志清理策略（如 `SystemMaxUse`、`MaxRetentionSec`）不影响已密封日志的校验能力，但删除后自然无法再验