我有一个系统，其 NFS 安装使用 krb5p 安全性。似乎一切都运行良好，除非时间向后移动（几个小时左右，不确定确切的阈值）。当时钟向后移动时，共享在尝试挂载（使用 autofs）时会报告“没有这样的文件或目录”。假设某处的加密检查之一正在检查向后时间并只是中止，这将是正常的默认行为。
我有一个测试用例，其中客户端/服务器是同一台机器，以及一些使用单独的计算机，结果相同。所有时间均通过 NTP 同步。在这个测试用例中，每个人使用的NTP服务器都被向后移动。
我意识到一个有点奇怪的测试用例，但这是一个完全离线的环境，该软件旨在处理任何类型的奇怪输入，例如操作员未正确配置 NTP（打字错误或其他），而这只是测试该边缘案件。
一旦我将时钟移回到现在或未来，共享就会在 kdestroy/kinit 周期后再次开始工作。
我已经尝试使用新的 kinit 进行 kdestroy，清除 sssd 缓存，重新启动 kadmin/k5rb-server 服务并完全重新启动系统（这会破坏 /tmp），但似乎没有任何效果。
我对系统有完全的控制权，所以我可以“重新安装”某些东西或擦除任何配置/数据文件，我只是找不到存储任何东西的位置来真正让 kerberos 或 NFS 忘记它曾经有一个未来的时间（假设我的理论甚至是正确的）。
系统：RHEL7.9
非常感谢。
更新 只是因为我们在下面有点偏离主题，我想澄清一下，我理解时间倒退是很奇怪的情况。虽然所有建议都值得讨论，但这个问题集中在如何修复软件来处理这种情况。我意识到有可能通过硬件解决这个问题，但我更好奇的是为什么它会具体失败以及如何恢复，而不是如何从一开始就防止它失败（如果这有意义）。虽然有一些硬件解决方案限制了这种边缘情况的潜力，但至少在我当前的系统限制下，没有任何解决方案可以将其降低到 0，而且遗憾的是，硬件选项不可行。软件选项也可能不可行，但只是试图理解它们。到目前为止似乎有效的一种解决方案是重新映像机器，但希望有一些不那么严厉的东西。
答案1
它不存储时间，它进行 vdso 系统调用以从操作系统内核中提取时间。如果它们不同步，那么就会失败。如果它处于离线状态，则查看带有 GPS 帽子的 RPi 并将其用作时间源。
答案2
你有一个错误的边缘情况。NTP设计除了首次部署时之外，不要向后跳跃时钟。即便如此，只有当主时钟错得无法修复时，它才会跳变。
向后跳跃时间会破坏许多应用程序的基础，因此这并不是一个真正的选择。数据库、Kerberos、甚至程序开发只是我想到的三个。
NTP 更喜欢改变时钟，而不是向前或向后跳跃。所以在你的例子中，它并没有向后跳，而是试图减慢时钟的速度。 NTP 实现还ntpd要求内核解释其对本地硬件时钟的读取：了解它是喜欢运行得快还是慢，并告诉内核偏移时钟值多少，以便在没有时钟的情况下获得相当准确的时间。外部时间源。
此外，如果您将时间提前超过几（五）分钟，您将不会带上您的家属；您必须手动重置他们的时钟。
本质上，如果您跳过时间，Kerberos 将停止工作；任何其他结果都是错误的。