在我们所有的盒子上，我们都可以通过密钥访问 ssh。所有密钥均受密码保护。此时 sudo 模式不是无密码的。因为在我们的设置中虚拟机的数量在增长，我们调查了Ansible的使用。
Ansible 本身在文档中说：
使用无密码 sudo 使事情更容易自动化，但这不是必需的。
这让我想到了无密码 sudo，我在这里找到了一些问题/答案。但是，我真的找不到关于无密码 sudo 本身的安全问题的任何信息。
将来可能会发生这种情况，用户 Bob 在机器 X 上的密码与 Y 不同。当 Bob 是 sudoer 时，这会给 Ansible 带来问题，即为所有框输入一个 sudo 密码。鉴于 ssh 是通过密钥完成的，密钥受密码保护，并且所有用户帐户都有密码（所以没有密码是不可能的）：在 sudo 文件中设置su bob时，安全性如何受到影响？NOPASSWD
NOPASSWD对安全性影响不大。它最明显的效果是在用户离开其工作站无人看管时提供保护：对其工作站具有物理访问权限的攻击者随后可以使用用户权限提取数据、执行操作和植入恶意软件，但不能提升其对 root 的访问权限。这种保护的用途有限，因为攻击者可以植入一个键盘记录器类型的程序，该程序会在用户下次在 sudo 提示符或屏幕保护程序中输入时记录用户的密码。
尽管如此，要求密码确实提高了攻击者的门槛。在许多情况下，针对不成熟的攻击者提供保护非常有用，特别是在无人值守的工作站场景中，攻击通常是机会之一，并且攻击者可能不知道如何在短时间内找到和配置谨慎的恶意软件。此外，当您没有 root 权限时，更难隐藏恶意软件——如果您没有 root 权限，则无法从 root 中隐藏。
在某些现实情况下，即使是老练的攻击者，缺少密码也能起到保护作用。例如，一台被盗的笔记本电脑：用户的笔记本电脑被盗，带有 SSH 私钥；小偷要么设法猜出密钥文件的密码（可能是通过蛮力），要么他从密钥代理的内存转储中获得对它们的访问权。如果检测到盗窃，这是调查该用户帐户最近活动的信号，这意味着应该检测到植入的恶意软件。如果攻击者只有用户级别的访问权限，他所做的任何事情都会在日志中留下痕迹；如果攻击者获得了用户的密码并运行了 sudo，那么现在所有的日志都被泄露了。
我不知道NOPASSWD您的用例的缺点是否平衡了优点。你需要平衡它与你情况的所有其他因素。例如，您似乎允许但不强制使用不同的密码。您可以改用集中式帐户数据库吗？您的系统之间需要多少遏制？您是否正在考虑支持不同 sudo 密码的 Ansible 替代方案？您是否考虑过其他身份验证机制？
有两种特定情况为什么您不想要无密码 sudo：
关于自动化：
我同意您可以无密码执行此操作，但通过不需要 sudo 密码，您实际上是在授予对自动化工具的所有访问权限。现在想想这个工具实际上需要做什么？它真的需要所有这些访问权限吗？可能不是。
Sudo 带有一个很好的功能，它允许您使用NOPASSWDsudoers 文件中的标志配置特定命令：
username myhost = (root) NOPASSWD: /sbin/shutdown
username myhost = (root) NOPASSWD: /sbin/reboot
出于某种原因，看起来没有人指出的一件事（如果我错了，请纠正我）是它使您运行的任何程序都可以在您不知情的情况下提升到 root 访问权限。通常，如果您在没有 sudo 的情况下不小心以非 root 用户身份运行恶意程序或脚本，那么虽然它仍然可以造成很大的破坏，但它仍然（除非单独利用）不会拥有 root 权限。因此，您至少不需要担心 rootkit 或任何东西。但是在 NOPASSWD 模式下，您没有这种保护。在您的用户下运行的任何程序都可以通过使用 sudo 重新调用自身来升级到 root。恶意软件仍然需要专门编程来执行此操作，否则它不会具有 root 访问权限，但是这样做的恶意代码呢？
鉴于事实 ssh 是通过密钥完成的，密钥受密码保护，所有用户帐户都有密码（所以 sub bob 是不可能没有密码的）
让我们在这里说清楚。用于保护 SSH 密钥的密码和用户帐户的密码不相同。
NOPASSWD只是允许用户以另一个用户的身份执行命令，而无需输入他的密码。它不影响用户在 SSH 进入系统时必须输入密码这一事实。