macOS 26.4 起登录钥匙串备份无法解锁：SystemKeys 恢复指南

二十年来，备份 Mac 上保存的登录信息只意味着一件事：把 login.keychain-db 复制到安全的地方，需要时把它放进新机器的 ~/Library/Keychains/，再输入密码即可。据 The Eclectic Light Company 的 Howard Oakley、Michael Tsai 以及多位开发者所述，这一做法在 2026 年 3 月 24 日发布的 macOS Tahoe 26.4 中已不再成立。单独一份登录钥匙串文件现在可能毫无用处：解锁它既需要你的密码，还需要一个受保护的第二文件，该文件位于创建这把钥匙串的那台 Mac 的 /var/db/SystemKeys 中。Apple 在发布时并未公布这一变化。首份官方说明是开发者技术说明 TN3137 的更新，六个月后的 2026 年 9 月 24 日才出现，大多数人也是那时才得知。如果你曾把钥匙串文件拖到全新安装的系统上，曾把副本存在 U 盘里当作保险，或者即将抹掉或更换一台 Mac，这篇指南就是写给你的。它把 Apple 已有文档说明的内容、他人观察到的现象和目前无人证实的部分区分开来，并提供了一张按场景逐项列出的表格，这是排名靠前的搜索结果所没有的。

要点速览

• 变化是真实的，但文档记录很差。 自 macOS Tahoe 26.4（2026 年 3 月 24 日）起，登录钥匙串可以引用 /var/db/SystemKeys 中受保护的熵文件。要解锁这样的钥匙串，需要密码和该文件。Apple 在技术说明 TN3137 中陈述了这一点；工作原理的细节来自 Howard Oakley 的测试。
• 只备份 login.keychain-db 已不再算备份。 缺少对应熵文件的副本，即使密码正确也无法解锁。Oakley 的建议很直白：没有连同熵文件一起保存的旧副本永远无法解锁，应视为已丢失。
• 据报道，由 Apple 掌控的 Mac 到 Mac 工具可以正常工作。 Oakley 报告称，时间机器会备份 /var/db/SystemKeys，迁移助理会复制熵文件。独立的虚拟机测试也发现迁移助理能带上钥匙串。第三方克隆工具必须明确支持该目录。
• 全新安装是最危险的时刻。 Michael Tsai 汇总的报告称，即使在同一台 Mac 上，抹掉磁盘后再把钥匙串文件复制回去也不起作用，因为抹除操作删除了熵密钥。
• iCloud 钥匙串和「密码」App 是另一套存储。 它们使用数据保护钥匙串，而不是基于文件的登录钥匙串，因此这次变化不会波及它们。真正需要在抹掉磁盘前迁移或导出的，是只存在于登录钥匙串中的内容。
• 不要随意关闭 SIP 这道门。 将钥匙串复制到另一台 Mac 的唯一有文档记载的方法，需要关闭系统完整性保护 (SIP)。Apple 表示这是用于调试，而不是产品功能。

变了什么，发生在哪个版本

我们要谨慎区分各方说法，因为论坛上的转述把细节弄得含混不清。这里有三个层面：Apple 的文档说了什么，Howard Oakley 等人观察到了什么，以及哪些仍未得到证实。

Apple 的文档说了什么

Apple 的开发者技术说明 TN3137: On Mac keychains 现在新增了一节，专门讲基于文件的钥匙串的备份。据我阅读，其内容如下。

• 从 macOS 26.4 开始，基于文件的钥匙串可以引用受保护的熵文件。要解锁这样的钥匙串，需要钥匙串密码和对应的受保护熵文件。
• 通过 security show-keychain-info -s 加钥匙串路径，可以输出钥匙串的 salt，据此找到熵文件。熵文件位于 /var/db/SystemKeys/，文件名就是 salt 值。
• 并非每把钥匙串都有熵文件。如果没有文件与 salt 匹配，说明该钥匙串不引用熵文件。
• 备份产品必须备份整个 /var/db/SystemKeys/ 目录。缺少这些文件，已备份的钥匙串可能无法使用。
• 若要通过把钥匙串复制到另一台 Mac 来进行调查，可将钥匙串文件复制到任意位置，并把熵文件复制到目标 Mac 的 /var/db/SystemKeys/ 中。访问该目录需要关闭系统完整性保护。
• 熵文件的名称、位置和格式明确不属于 API，可能随时更改，因此不应围绕它们开发产品。
• 系统会把相关文件的信息写入系统日志，日志类别名为 dp_login。

我只读到了技术说明的机器可读版本，所以我的措辞只是接近原文的转述。这是我找到的、关于此主题的唯一一份 Apple 文档。我没有在 macOS 26.4 的发行说明中找到这项变化，而 Apple 安全更新页面列出的 macOS Tahoe 26.4（2026 年 3 月 24 日）也没有关于钥匙串存储的条目。这与 Oakley 对该变化六个月来一直未见文档说明的抱怨相吻合。

Howard Oakley 等人观察到了什么

Oakley 的文章给出了实际情况。他 9 月 14 日的文章 How can you copy or restore keychains? 将这一变化描述为把登录钥匙串的访问权限绑定到单台 Mac，并报告称，非登录的基于文件的钥匙串仍然正常工作，在 macOS 26.3.1 或更早版本中创建的基于文件的钥匙串也是如此。他 10 月 2 日的文章 How to copy login keychains that can be unlocked 给出了有文档记载的操作步骤，也是备份工具相关说明的来源。他 10 月 3 日的文章 What changed in macOS Tahoe 26.4, take 2 把这项变化列入他第一次遗漏的一批条目：新的受 SIP 保护的目录、时间机器将其纳入备份、迁移助理复制熵文件，以及 security show-keychain-info 新增的 -s 选项。

Michael Tsai 在 Locked Down Passkey and Keychain Backups（9 月 24 日）中汇总了各方反应。他报告称，熵文件经过加密，不关闭 SIP 就无法访问，把钥匙串恢复到另一台 Mac 会失败，即便是同一台 Mac，在全新安装后也会失败。我只读到了他文章的摘要，无法复现这些说法。

另一项独立验证来自德国网站 Born City，该站报道了虚拟机测试。在虚拟 Mac 之间复制 login.keychain-db，无论是从 Tahoe 26.6.2 到 26.6.2，还是从 26.6.2 到 macOS 27 候选发布版，即使密码正确也都会以错误 -2147413984 失败，而迁移助理在所有测试场景中都成功带上了钥匙串。同一篇文章把失败归因于保存在安全隔区中的某个密钥，这是作者的解释，而非 Apple 的说法。

尚未证实的部分

• macOS 27 是否有相同表现。 除 Born City 的候选发布版测试外，我没找到测试 27.0 或 27.0.1 的来源，技术说明也没有说规则有所不同。假定 26.4 的行为会延续，只是一种假设。
• 第二个秘密究竟是什么。 9 月 14 日的文章推测可能涉及安全隔区或 APFS 卷特定的密钥，并表示 Apple 尚未澄清是哪一种。10 月 2 日的文章表明，至少在 Oakley 的测试中，关闭 SIP 后将熵文件连同钥匙串一起复制到另一台 Mac 就足够了。这两个发现并不明显吻合，我也没有看到 Apple 给出解释。
• 具体哪些配置受影响。 Oakley 指出，26.4 之前创建的钥匙串仍可能正常工作，TN3137 也说有些钥匙串根本不引用熵文件。我读到的任何材料都没有说明：一把在 26.3 上创建、之后在 26.4 或更高版本上使用过的钥匙串，是否会获得熵文件。

一项未经 Apple 证实的相关说法

同一周，Tsai 还链接了 Bob Gendler 的一篇文章，涉及一个被标记为 CVE-2026-43728 的所报告问题：据称在存在其他解锁因素时，用错误的密码也能成功解锁钥匙串，并引用了一条与此相符的手册页说明（参见 Accessing the Keychain Without the Password）。我无法在 Apple 一侧证实这一点：我查看的 Apple 安全更新页面既没有该编号的条目，也没有 26.4 至 26.7.1 各版本中与钥匙串相关的条目，而且在一台运行 macOS 26.5.2 的 Mac 上，我也没能在 security 手册页中找到被引用的那句话。请将其视为第三方报告，未经 Apple 证实。它同时也是与本文所述问题不同的另一个问题，因此不会改变下面的任何备份建议。

通俗讲解其工作原理

把登录钥匙串想象成一个上了锁的盒子。多年来，这个盒子就是一个文件 ~/Library/Keychains/login.keychain-db，钥匙就是密码。有了文件和密码，你在任何地方都能打开它。

从 26.4 起，这个盒子可以有第二把锁。各来源在以下几点上是一致的：

1. 文件会记录它需要哪个熵文件。 对于基于文件的钥匙串，security show-keychain-info -s 命令会输出一个 salt。Oakley 的示例输出是 salt= 后面跟着一长串十六进制 salt。/var/db/SystemKeys 中的熵文件就以这个 salt 命名。
2. 熵文件位于受 SIP 保护的目录中。 据 Oakley 所述，/var/db/SystemKeys 是一个新目录，除非关闭 SIP，否则无法读取或写入。Tsai 的汇总补充说，其中的文件是加密的。
3. 解锁需要两者齐备。 仅有密码已不够。在创建钥匙串的那台 Mac 上，这一切都看不见：你登录，钥匙串解锁，系统在你毫不知情的情况下读取熵文件。
4. 熵文件存放在卷上。 抹掉磁盘会连同该目录一起删除，这就是为什么全新安装如此要紧，也是时间机器纳入该目录意义重大的原因。

各来源没有确立的是安全隔区所起的作用。早期报告，包括 Oakley 9 月 14 日的文章和 Born City 的文章，都说加密与它或某个机器特定的秘密有关。Oakley 写道，Apple 尚未澄清这一点。Tsai 引用了一位评论者的话，指出所有 Apple 芯片 Mac 以及部分 Intel Mac 都带有安全隔区处理器，因此这个问题可能波及数百万人。只有已有文档说明的机制（密码加熵文件）才是你能据以行动的。

还有一个容易引起混淆的区别。以上所有内容针对的都是较旧的、基于文件的登录钥匙串。TN3137 还介绍了第二种，即数据保护钥匙串，它随 iCloud 钥匙串一起来到 Mac，也是 iOS 所使用的。那是另一套独立的存储，这就引出了人们最先问的问题。

登录钥匙串、iCloud 钥匙串、「密码」App、通行密钥：哪些受影响

存储	是什么	是否受 26.4 变化影响？	来源
登录钥匙串（login.keychain-db）	基于文件的钥匙串，每个用户一份，是 Mac 上的默认钥匙串	是。需要密码加熵文件	TN3137、Oakley
系统钥匙串	由整台 Mac 共用的一个基于文件的钥匙串	我读到的任何来源都没有提及	未知
你创建的其他基于文件的钥匙串	独立的 .keychain-db 文件	否，据 Oakley 所述它们正常工作	Oakley，9 月 14 日
iCloud 钥匙串 / iCloud 密码	数据保护钥匙串，通过你的 Apple 账户同步	据 TN3137 所述，不受这次变化影响	TN3137
「密码」App	密码、通行密钥和验证码的前端界面	不涉及登录钥匙串文件本身	Apple 密码指南
保存在 iCloud 钥匙串中的通行密钥	已同步的凭据	不受这次变化影响，见下方说明	TN3137、Tsai

TN3137 指出，iCloud 钥匙串需要数据保护钥匙串，启用时在钥匙串访问中显示为 iCloud 钥匙串，停用时显示为本地项目。它还说，macOS 11 及更高版本会同步所有项目类别。换言之，如果你的密码是通过 iCloud 同步的，那么 Apple 的同步服务中就有一份与你的 Apple 账户绑定的副本，而不是你随身携带的某个文件。在新 Mac 上恢复它们，只需登录并重新打开 iCloud 密码，不需要复制文件。

这就留下了陷阱：有的项目可能在你不知情的情况下存放在登录钥匙串里。 Tsai 的讨论提到 Google Chrome、Zoom、MailMate、Vienna RSS 和 Xcode 会把凭据存放在那里。旧的邮件密码、VPN 秘密、客户端证书和开发者令牌也常常放在那里，所以在抹掉磁盘前花十分钟检查一下是值得的。

通行密钥

Tsai 那篇文章的标题提到了通行密钥备份，因此有必要精确说明我能证实和不能证实的内容。通过系统创建并经 iCloud 钥匙串同步的通行密钥，存放在数据保护钥匙串的体系中，而不是登录钥匙串文件里，所以 26.4 的熵文件变化并不会让它们面临风险。我无法从所读来源确定的是，Apple 的通行密钥备份与导出行为同这项变化相比如何，因为 Tsai 文章中关于通行密钥的细节我没能读完整。我确实读到的 Apple 官方导出指引说，你可以把密码导出为 CSV 文件，但无法导出 Wi-Fi 密码、与群组共享的密码（除非群组是你创建的）或使用 Apple 登录的账户。它没有说通行密钥会出现在该文件里，所以不要打算导出通行密钥。请指望它们保存在 iCloud 钥匙串中，并且对重要的网站，确保另有一种登录途径，例如恢复码或第二种登录方式。

场景表：登录钥匙串中的项目会怎样

凡我写「未知」之处，都是我读到的来源没有涉及该情形；对于「可行」或「失败」，我会注明是谁报告的。其中没有任何内容是我自己测试的。

场景	结果	来源与说明
在同一台 Mac 上原地升级（例如升级到 26.7.1 或 27.0.1）	预期可行，没有任何来源直接测试过	Oakley 说从同一台 Mac 备份的钥匙串可以工作。原地升级保留同一个卷和同一个 /var/db/SystemKeys，所以没有东西被分开。没有来源描述过对这条确切路径的测试。
使用迁移助理，在线从旧 Mac 迁移到新 Mac	可行	Oakley（9 月 14 日和 10 月 3 日）说迁移助理会复制熵文件。Born City 的虚拟机测试发现，它在所有场景下都带上了钥匙串。Tsai 的汇总提到有评论者称，只有在旧 Mac 充当网络服务器时才行得通，所以请在两台 Mac 都开机的情况下运行，而不是从已存储的备份运行。
从时间机器备份使用迁移助理	未知	Oakley 说时间机器会备份 /var/db/SystemKeys。我读到的来源都没有说明，当该备份随后被用作迁移来源、迁移到另一台 Mac 时会发生什么。
时间机器完整恢复到同一台 Mac（或恢复到同一台 Mac 更换后的内置硬盘）	可行，据 Oakley 所述	Oakley 说时间机器自 26.4 起会备份该目录，并自动恢复熵文件。关于更换逻辑板的例外情况，请见下文。
时间机器恢复到另一台 Mac	未知	我读到的来源均未涉及。迁移助理是有文档记载的迁移到新 Mac 的途径。
使用 Carbon Copy Cloner 制作的可启动克隆，再恢复	备份端可行，恢复端未知	Oakley 报告称 Mike Bombich 确认，因为 CCC 基于卷快照工作，所以无需特殊步骤即可备份 SystemKeys 文件夹的内容。至于把该克隆恢复到另一台 Mac 时会怎样，则没有说明。
使用 SuperDuper 制作的可启动克隆，再恢复	未知，附一条线索	Tsai 文章中的一位评论者说，SuperDuper 可以借助 Apple 的 asr 工具复制所需密钥。我没有看到开发者本人的声明。依赖它之前请向厂商核实。
手动把 login.keychain-db 复制到另一台 Mac	不可行	Oakley、TN3137 和 Born City 一致认为如此。Born City 报告密码正确时出现错误 -2147413984。
手动复制钥匙串及其熵文件，并在关闭 SIP 的目标 Mac 上放入 /var/db/SystemKeys	可行，据 Oakley 的文档记载的步骤	步骤与注意事项见下一节。我没有运行过。
全新安装后，把旧钥匙串文件拖回（同一台 Mac）	不可行	Tsai 的文章报告称，全新安装后恢复该文件会失败，因为抹除删除了熵密钥。Oakley 说，没有连同熵文件一起保存的登录钥匙串永远无法解锁。
从时间机器备份中恢复单个 login.keychain-db	视情况而定	如果该钥匙串 salt 对应的熵文件仍在当前卷上，这个组合就是各来源描述的可行组合。全新安装后，或在另一台 Mac 上，则会失败。没有来源直接测试过这条恢复路径。
硬件故障导致更换逻辑板，或 DFU 恢复	不可行	Oakley 9 月 14 日的文章把这些列为无法解锁登录钥匙串的情形，并警告说，失去对这台 Mac 的访问权限就意味着失去其中的内容。
在 26.3.1 或更早版本中创建的钥匙串，非登录的基于文件的钥匙串	正常工作	Oakley，9 月 14 日。

从表中可以归纳出两条规则：安全的路径是让 Apple 自己的工具携带整个系统状态，风险的路径则是把熵文件与钥匙串分开，要么单独移动钥匙串，要么抹掉存放它的磁盘。

抹掉或更换 Mac 之前：检查清单

请在点击「抹掉所有内容和设置」之前、在从恢复模式重新安装 macOS 之前，以及在把 Mac 交给可能更换逻辑板的维修店之前完成这些步骤。目标是确保没有任何重要内容只存在于登录钥匙串中。

1. 检查 Mac 的状态并制作真正的备份

先确认你运行的版本；下面的修复路径假定为 26.4 或更高版本。

sw_vers -productVersion

先做一次完整的时间机器备份。Oakley 报告称该备份现在包含 /var/db/SystemKeys。我们的时间机器故障排除指南涵盖了备份失败的情况，如果你的备份目标是通过 SMB 连接的 NAS，26.4 SMB 备份修复则说明了 26.4 的另一个独立问题。如需更完整的方案，请参阅我们的备份策略指南。请把时间机器备份当作安全网，而不是全部答案：它在整机恢复时能保护你，但对只能找回单个文件的情形无能为力。

2. 打开钥匙串访问，看看里面到底有什么

在一台运行 macOS 26.5.2 的 Mac 上，我确认钥匙串访问仍然位于 /System/Library/CoreServices/Applications/Keychain Access.app。它已不在旧的「应用程序/实用工具」文件夹中，所以请用聚焦搜索来找它，或从终端打开：

open "/System/Library/CoreServices/Applications/Keychain Access.app"

在边栏中查看默认钥匙串下的列表。根据 TN3137，基于文件的钥匙串条目名为 login，数据保护钥匙串则名为 iCloud 或本地项目，取决于 iCloud 钥匙串是否开启。点按 login，再点按密码和证书类别。按种类和修改日期排序，让陈旧而明显重要的项目排在前面。login 中的一切都是抹掉磁盘时有风险的内容，iCloud 下的内容则会与你的 Apple 账户同步。

如果你更喜欢用终端，security 手册页记载了这两条只读命令：

security list-keychains
security show-keychain-info ~/Library/Keychains/login.keychain-db

第一条列出当前搜索列表中的钥匙串。第二条输出你指定的钥匙串的设置；在我检查的那台 Mac 上，本地手册页没有列出 Oakley 和 TN3137 所描述的 -s 选项，所以如果想要 salt，请使用这些来源中的形式，即 security show-keychain-info -s 后接路径，并预期会弹出密码提示。把 salt 值记下来很有用。它能告诉你 /var/db/SystemKeys 中哪个文件属于这把钥匙串，以后如果需要证明某份备份包含它，这一点就很重要。

此外还有 security dump-keychain，手册页说它会转储钥匙串内容；其 -d 选项会转储解密后的数据。我没有运行过，所以请妥善保管任何输出，用完即删。

3. 导出能导出的内容

诚实的总结是：有些内容很容易导出，有些要费些力气，有些则完全无法导出。

• 「密码」App 中的密码。 Apple 记载的路径是「文件」，然后选择「将所选密码导出到文件」或「将所有密码导出到文件」。结果是一份 CSV，正如 Apple 警告的，它未加密，任何能接触到该文件的人都可以看到。把它导入你的密码管理器，然后删除这份 CSV。Apple 还说，导出内容不能包含 Wi-Fi 密码、你未创建的群组所共享的密码，或使用 Apple 登录的访问权限。我们关于 macOS 27 中的「密码」App 的文章介绍了该 App 的其余部分。
• 只存在于登录钥匙串中的项目。 旧版 App 存储的密码会出现在钥匙串访问中，但可能不会出现在「密码」App 里。我找到的一份用户报告说，选中已存储的密码时，钥匙串访问中的「导出项目」命令是禁用的，所以不要以为可以用菜单命令导出这些密码。对每个重要项目，请将其打开，勾选显示密码，完成身份验证，然后把值记录到你的密码管理器中。这很繁琐，但对于几十个项目来说，也是唯一可靠的途径。
• 证书和身份。 security 手册页记载了一条导出命令，接受类型（包括 certs 和 identities）和格式（包括 pkcs12）。其一般形式如下：

security export -k ~/Library/Keychains/login.keychain-db -t identities -f pkcs12 -o ~/Desktop/identities.p12

手册页说，不带 -P 时，包装口令会通过图形界面提示来请求，这是更好的选择，因为命令行中的口令会留在你的 shell 历史记录里。我没有运行过这条命令。被创建工具标记为不可导出的私钥可能会拒绝导出，这是此类密钥的预期行为，不是备份的缺陷。如果你依赖客户端证书来使用 VPN 或工作门户，请询问签发方能否重新签发；这往往比和导出过程较劲更快。

• Wi-Fi 密码。 Apple 将其列为无法从「密码」App 导出的内容。请记下哪些网络重要，以及每个密码写在哪里。
• 无法取出的内容。 由某个 App 存储且访问规则只允许该 App 读取的秘密，以及任何只存在于你再也无法解锁的钥匙串中的内容。对于这些，途径是厂商自己的导出、登出或重新验证流程。

4. 把幸存的内容迁到持久的地方

对每个你在意的项目，决定它接下来该放在哪里。如果想使用 Apple 的同步存储，请在系统设置中依次进入你的 Apple 账户、iCloud，打开 iCloud 的密码与钥匙串。或者使用提供自身加密导出功能的第三方密码管理器。无论哪种，目标都不应是依赖这台特定 Mac 的文件。

请在另一台设备上检查，某个网站是否仅凭同步的副本就能登录。如果可以，该项目就不会受这次变化影响。

5. 准备抹除

我们的恢复出厂设置指南涵盖了抹除本身；只有在确认同步副本完整后，才退出你的 Apple 账户。对于新 Mac，请在旧 Mac 开机的情况下运行迁移助理，如果它卡住，请参阅我们的迁移助理故障排除指南。在新 Mac 真正打开了你的登录项之前，请保持旧 Mac 的数据完好。

复制钥匙串并使其可解锁的文档化步骤

我没有运行过这一步骤，也没有在任何一台 Mac 上测试过。这是 Howard Oakley 的文档化方法，结合了 Apple TN3137 的说法，并明确写出了要求和风险。

文档记载的步骤

1. 在源 Mac 上，找到你想复制的钥匙串的 salt。Oakley 和 TN3137 给出的形式是 security show-keychain-info -s 后接钥匙串路径。系统会提示你输入钥匙串密码。输出的末尾是一长串十六进制 salt 值。
2. 你需要的熵文件是 /var/db/SystemKeys/ 后接该 salt 值。据 TN3137 和 Oakley 所述，读取该目录需要关闭 SIP。两个来源都没有明说源 Mac 是否也必须关闭 SIP 才能读取该文件，但由于两端适用相同的目录保护，请做好这一准备。
3. 把钥匙串文件及其熵文件复制到目标 Mac。钥匙串可以放在任何位置。Oakley 的示例把它放在「文稿」的一个子文件夹中。
4. 在目标 Mac 上，关闭 SIP 后，把熵文件以相同的名称放入 /var/db/SystemKeys。
5. 重新启用 SIP。
6. 打开复制过来的钥匙串并输入其密码。

要关闭和重新启用 SIP，Apple 记载的方法是启动到恢复环境 (recoveryOS)，并使用其中的终端。相关命令如下：

csrutil disable
csrutil enable

csrutil disable 为已安装的系统关闭 SIP，并需要重新启动。csrutil enable 再将其打开。要随时检查当前状态，请在终端中运行 csrutil status。在我做这项调研所用的 Mac 上，它报告 SIP 已启用，这是预期的默认状态。在 Apple 芯片 Mac 上，进入 recoveryOS 的方法是先关机，然后按住电源按钮，直到出现启动选项，再选择「选项」。

要求与风险

• 复制这一步需要关闭 SIP。 这是核心要求。关闭期间，系统文件的保护会降低，包括你正在操作的这个目录本身。请让这段时间尽量短，并且在此期间不要安装任何东西。
• 密码和熵文件都必须正确。 名称不对的文件复制过去也没有用。如果把错误的文件放进了 /var/db/SystemKeys，你一无所获，反而向受保护的系统目录写入了内容。
• 它明确不是受支持的功能。 TN3137 说，熵文件的位置、名称和格式不属于 API，可能随时更改，而且该步骤用于开发和调试。macOS 更新可能改变这一安排，使你保存的副本失效。
• 熵文件是敏感的。 它连同你的密码可以解锁钥匙串，所以不要把两者不加密地存放在一起，也不要把它们发送到任何地方。
• 它解决不了源 Mac 已不存在的情形。 如果那台 Mac 已经损坏或磁盘已被抹除，就没有熵文件可复制。

何时不要这样做

不要把这个步骤当作你的常规备份方式，也不要仅仅因为 Mac 要求输入一个你记不起来的钥匙串密码就照着做。如果想迁移到新 Mac，迁移助理才是受支持的途径。如果你只是想知道钥匙串里有什么，在原来的 Mac 上用钥匙串访问就能做到。如果你对 recoveryOS 和终端不熟悉，或者这台 Mac 的 SIP 由 IT 部门管理，请放弃。它只适合由接受暂时降低 SIP 保护的人，对仍在手边的旧 Mac 做一次性恢复。

如果你已经无法访问

以下是基于上述来源的实情，不抱虚假的希望。

可能可以恢复的内容

• 任何已同步到 iCloud 钥匙串的内容。 在新 Mac 上登录你的 Apple 账户，打开「密码与钥匙串」，等待项目同步过来。
• 同一台 Mac 上制作的时间机器备份中的项目。 如果你仍有那台 Mac，或者把完整的时间机器备份恢复到同一台 Mac，Oakley 说熵文件会被包含并恢复。
• 在 macOS 26.3.1 或更早版本中创建的钥匙串。 Oakley 说这些可以工作。如果你有 2026 年 3 月之前的旧副本，请先试一试，不要一上来就往最坏处想。
• 任何仍带有熵文件的副本。 如果你手动复制了钥匙串，并且还有来自同一台 Mac 的 /var/db/SystemKeys 备份，那么上述文档化步骤就是你的出路。

可能无法恢复的内容

• 来自 macOS 26.4 或更高版本、没有连同熵文件一起保存、且来源 Mac 已不存在或已被抹除的登录钥匙串。 Oakley 明确说你将永远无法解锁它，对于失去对 Mac 的物理访问、更换逻辑板或 DFU 恢复的情形，他的说法也一样。
• 任何你只存放在那把钥匙串里、没有同步、没有导出、也没有副本的内容。

不要为声称能绕过密码的「钥匙串恢复」服务付费。问题在于缺少第二项输入，而不是忘记了密码，而且我没有找到任何来源描述过针对任意副本的绕过办法。

现在该做什么：保持 Mac 和备份硬盘原封不动，然后按以下顺序检查：iCloud 钥匙串、你的密码管理器、任何时间机器备份、任何克隆、任何旧 Mac，最后是各账户的重置流程，先从电子邮件和你的 Apple 账户开始，因为它们能解锁其余的一切。

给管理员和编写钥匙串备份脚本者的说明

如果你管理 Mac，或者有一个每晚复制 ~/Library/Keychains 的脚本，请在证明无误之前，假定你在 26.4 及更高版本上的备份是不完整的。

• 审查脚本。 只复制 login.keychain-db 的脚本所产生的文件可能毫无用处。TN3137 说备份产品应备份整个 /var/db/SystemKeys/ 目录。该目录受 SIP 保护，因此以普通用户运行的脚本，甚至在 SIP 开启时以 root 运行的脚本，都可能无法读取它；除了基于快照的工具外，我没找到说明在 SIP 开启时如何读取它的来源。Oakley 关于 CCC 的说明很有启发：它基于卷快照工作，所以无需特殊步骤就能看到该目录。
• 不要硬编码路径。 TN3137 说名称、位置和格式不属于 API。如果你把 salt 到路径的映射写进了工具，它可能在任何一次更新中失效。仅在诊断和日志中使用 security show-keychain-info -s。
• 测试恢复，而不只是备份。 无法在目标机上打开的备份就不是备份。建立一项测试，恢复到一台干净的 Mac 或虚拟机，并尝试解锁一把测试钥匙串。如果你用虚拟机来做，Born City 的虚拟机测试条件（不同的 MAC 地址，每台虚拟机至少三个 CPU 核心和 12 GB 内存）是有用的参考。
• 检查 macOS 27。 你的设备群很可能同时包含 Tahoe 26.7.1 和 Golden Gate 27.0.1。不要假定行为完全相同；请在两者上都运行恢复测试。使用我们的 macOS 版本工具查看你的设备运行的是哪些构建版本。

常见问题排查

复制过来的钥匙串要求输入密码，却拒绝了正确的密码

Oakley、Apple 开发者论坛和 Born City 都描述了这个症状；Born City 报告了错误 -2147413984。一位论坛发帖者看到，复制出来的登录钥匙串在 26.4 中拒绝解锁，而原件保持解锁状态，一位 Apple 工程师要求他提交反馈助理报告。最可能的原因是缺少熵文件，而不是密码错误。不要重置原件的密码；请检查源 Mac 是否仍然存在。

反复弹出密码提示是另一个问题

如果提示是在更改账户密码或恢复之后开始的，请参阅我们的 Tahoe 登录钥匙串密码提示指南。只有在钥匙串是从另一个卷或另一台 Mac 复制来的情况下，才怀疑是熵文件的问题。

show-keychain-info -s 没有输出 salt

TN3137 说并非每把钥匙串都引用熵文件。如果命令没有输出 salt，或者 /var/db/SystemKeys 中没有匹配的文件，说明该钥匙串不需要熵文件。对于旧钥匙串，这是好消息。另外请检查你传入的是文件的完整路径，并且使用的 macOS 版本支持该选项；26.5.2 的 Mac 上的本地手册页没有列出 -s 标志，尽管 Apple 和 Oakley 都描述了它。

常见问题

Apple 真的改变了登录钥匙串的工作方式吗？

根据 Apple 的 TN3137 技术说明，自 macOS 26.4 起，基于文件的钥匙串可以引用受保护的熵文件，解锁需要密码加该文件。Apple 在发布时没有宣布这一点；据 Howard Oakley 所述，技术说明的更新是在 2026 年 9 月 24 日，即 26.4 于 2026 年 3 月 24 日发布六个月之后。

我还能把 login.keychain-db 复制到新 Mac 吗？

单独复制不行。各来源一致认为，仅凭这个文件无法在另一台 Mac 上解锁，即使密码正确也是如此。有文档记载的变通办法是，在关闭 SIP 的情况下，把匹配的熵文件复制到目标 Mac 的 /var/db/SystemKeys 中，但 Apple 把它定位为用于调试。要真正迁移到新 Mac，请在旧 Mac 开机的情况下使用迁移助理。

这会影响 iCloud 钥匙串和「密码」App 吗？

根据 TN3137，iCloud 钥匙串使用数据保护钥匙串，这与基于文件的登录钥匙串是不同的存储，所以这次变化针对的是登录文件。通过 iCloud 密码同步的项目与你的 Apple 账户绑定。请在抹掉磁盘前检查有哪些内容只存在于登录钥匙串中，因为这些才是有风险的项目。

时间机器会恢复我的钥匙串吗？

Howard Oakley 报告称，时间机器自 26.4 起包含 /var/db/SystemKeys，并会自动恢复熵文件，所以恢复到同一台 Mac 的完整恢复应该可行。单独恢复一个钥匙串文件，或恢复到另一台 Mac，我读到的来源均未涉及，所以请将这些情形视为未知。

macOS 27 也一样吗？

未知。Apple 的技术说明没有区分不同版本，而且除了一次在候选发布版上、与 26.4 行为一致的虚拟机测试外，我没有发现任何针对 27.0 或 27.0.1 的公开测试。请假定规则相同，并在依赖它之前先在 27 上测试你的恢复路径。Apple 也可能随时更改熵文件的细节。

有没有办法不用熵文件就解锁复制出来的钥匙串？

我读到的来源都没有描述这样的办法。Oakley 说，26.4 起、没有连同熵文件一起存放的旧登录钥匙串不妨直接删除，因为它们永远无法解锁。一份关于钥匙串解锁接受了错误密码、被标记为 CVE-2026-43728 的第三方报告，未在 Apple 的安全页面上得到证实，不应被视为一种恢复方法。

结语

macOS 26.4 的现实教训是：登录钥匙串不再是一个你可以随身携带的文件，而变成了系统状态的一部分。密码仍然必不可少，但已不再足够，第二项要素存放在普通工具看不到的目录里。据 Oakley 和独立的虚拟机测试所述，Apple 自己的迁移和备份工具似乎会替你处理这一点。手工制作的副本、全新安装后再拖放恢复，以及没有捕获 /var/db/SystemKeys 的第三方备份则不行。一些细节，例如安全隔区的确切作用，以及 macOS 27 是否不同，仍未得到证实。

所以请改变习惯。在任何抹除、更换或维修之前，先用时间机器备份，看看登录钥匙串里有什么，把重要的内容迁到 iCloud 密码或密码管理器，并在另一台设备上确认。新 Mac 请使用迁移助理。在新 Mac 证明它能打开你的登录信息之前，请保留旧 Mac。如果你手里只有一份旧的钥匙串文件，请先弄清它的熵文件是否还在，再决定是否放弃。

相关阅读：2026 年最佳 Mac 备份策略、迁移助理卡住或速度慢、Tahoe 的 Mac 安全与隐私指南