我见过的一种方法是：拆分密码。这是为了对敏感服务器进行 SSH 访问：创建了许多 SSH 密钥，并在服务器上标记为“已授权”。每个私钥都有一个长密码保护，每个用户只知道密码的一半。

只要没有太多管理员，这很粗略但有效。对于N个“双重控制”管理员，您需要N(N+1)/2 个这样的密钥（例如，如果您有 10 个管理员，则需要 55 个密钥），这通常是可以接受的。每个管理员只需要记住一个“半密码”。sudo可以通过设置N(N+1)/2 个特定帐户来扩展相同的概念（例如，管理员 Bob 和管理员 Dave 类型sudo -u bob_dave thecommand和帐户bob_dave是相关组的一部分，或者可能被赋予 UID 0 以便作为别名root） .

双重控制在以下意义上是预防性的：攻击者必须贿赂两名管理员而不是一名管理员（这意味着他将花费两倍的品脱吉尼斯啤酒）。

我不知道在操作系统级别为两人概念设计的任何内置系统。虽然可以编写一个新版本的 sudo/PAM 来实现这一点，但在我看来，在应用程序级别执行比在操作系统级别更好，在应用程序中针对您的特定目的进行定制。数据可以通过多个密钥（属于不同用户）进行加密，以确保root用户无法轻易绕过控制。

您的设想是什么——两个人坐在同一张桌子上，用户 A 进行身份验证，然后用户 B 进行身份验证，然后执行 sudo 命令？或者用户 A 输入sudo emacs /etc/ssh/sshd_config，一条消息被发送给用户 B，用户 B 必须使用他们的身份验证详细信息才能确定用户 A 可以在编辑文件之前编辑文件？

再次使用标准工作流程，您可以在打开文件或创建更改之前以超级用户身份打开文本编辑器。因此，您可以想象得到用户 B 的许可，sudo emacs /etc/ssh/sshd_config但是一旦 emacs（作为超级用户）打开，您就可以开始编辑任意数量的其他文件（例如 open 和 edit /etc/shadow，替换另一个去度假的管理员的哈希）甚至打开来自 emacs 的超级用户 shell（/var/log/auth.log在标准设置下 没有任何重新提示凭据或额外记录 sudo 的使用）。

有点相关，可以使用yubikey或google为 ssh 设置两个因素身份验证。因此，您可以设置一个场景，您需要两个因素身份验证才能登录，要求两个人在用户登录时都在场（例如，如果日志中记录有任何恶意，两个人都可以被解雇），每个成员只有一个登录的因素。

并不是我所知道的逐个命令，尽管您可以通过使用 sudo 和双因素身份验证（例如，yubikey）来模拟它，并为每个密钥持有者提供一个因素。

但我确实有一个客户想要这样的东西，所以我们在相关的盒子上安装了tripwire。系统管理员有 sudo 权限来运行它，但没有密钥；管理层有钥匙，但没有特权。当然，我们的管理员可以随心所欲地把事情搞砸，但是这些变化的每晚tripwire摘要都会通过电子邮件发送给管理层，他们不会签署它们（通过在tripwire --update ...命令中输入密码，并通过在更改日志），直到我们解释了更改是什么以及原因。

这不是万无一失的，但单个系统管理员（或管理团队的单个成员）很难在检测不到的情况下绕过。

虽然如果您对添加软件有限制，这可能是一个问题，但编写一个“su”版本会相对简单（这是传统实现的骨架）。

可以将 2 个用户身份验证实现为 pam 模块，但我认为您不能将它与其他提供身份验证的模块堆叠在一起 - 因此使用单个 setuid 二进制文件，它独立地为每个用户调用 pam。

（为什么每个 pam 客户端都使用'goto'！）