大多数 Linux 发行版默认启用带有公钥-私钥身份验证的 SSH。这很棒，因为当我为远程用户创建帐户时，我不必通过电子邮件向他们发送敏感信息（密码）。
然而，当这些用户需要运行时，这个过程变得毫无用处sudo——服务器仍在询问他们的密码。这意味着我仍然需要为这些用户生成密码，并弄清楚如何安全地将密码发送给他们。
我知道sudoers文件和NOPASSWORD参数。但是，启用它我感到不安。sudo在用户可以运行命令之前，我仍然需要某种身份验证。
在对这个主题进行一些研究时，我发现了 pam_ssh_agent_authsudo项目，据我了解，它启用了与用于 ssh 连接但用于命令的相同的私钥/公钥身份验证。
似乎有了这个模块，我们就可以拥有完全无密码的帐户。
为什么这个模块或类似过程不是标准 Linux 发行版配置的一部分？是否有一些我遗漏的安全警告，为什么它没有被更广泛地采用？为什么密码 sudo被认为比公钥/私钥 sudo更安全？
我正在尝试一种不需要创建和管理密码的不同方法：我使用用户的公钥设置基于密钥的身份验证，禁用 ssh 的基于密码的身份验证，并使用空但过期的密码设置用户帐户（passwd -de） . 这样，用户在第一次登录时就会收到提示，并且可以选择自己的密码。
我对空密码感到有些不安，但据我所知，只要禁用 ssh 的密码身份验证并且没有其他需要身份验证的服务正在运行（IMAP 或其他东西），就可以了。对此有何看法？
我建议甚至避免在您的系统上安装 sudo：这是一个额外的攻击媒介，通常没有理由拥有它。如果您有兴趣了解有关该主题的更多信息，我写了一篇关于 sudo（错误）用法的文章：http: //dmitry.khlebnikov.net/2015/07/should-we-use-sudo-for-day-to-日.html
回复：最初的问题 - 如果您需要一些特权命令由非特权用户执行，您可以使用以下技巧：
from="127.0.0.1",command="your_desired_command_here",no-pty,no-port-forwarding,no-agent-forwarding您还可以进一步限制 SSH 会话，请参阅“man sshd”）。请注意，密钥应与此标头用空格字符分隔。例如，如果特权帐户是 r_service（使用创建useradd -om -u0 -g0 -d /root/service -s /bin/bash r_service），则从非特权帐户调用该特权命令将类似于：
$ ssh -i ~/.ssh/privileged_command r_service@0
这样，您将授予您的用户执行该特权命令，而不会损害安全模型。
在我看来，sudo对于服务器管理员来说有点矫枉过正。如果人们登录并且他们具有 root 访问权限（通过某种机制），他们通常会执行维护任务，他们将使用 sudo 超过 90% 的时间。sudo 的目的是为登录的帐户在不受信任的应用程序和类似管理员的任务之间提供一些分离，并让用户意识到他们正在更改系统（并且必须小心）。对于台式机，两者都适用。然而，对于服务器，大多数任务已经需要 sudo，所以这两点都变得很弱。sudo它的细粒度控制具有一些优势，但是要依赖其日志记录功能，您需要设置远程日志记录，否则具有 root 访问权限的人可能会伪造过去的日志。
是否有一些我遗漏的安全警告，为什么它没有被更广泛地采用？
pam_ssh_agent_auth需要 ssh-agent 转发才能在 ssh 上工作。但是，使用它有点毫无意义，因为在用户帐户下运行的每个（非 cgrouped）进程都可以使用代理以 root 身份执行命令。这使得每个这样的进程都能运行sudo，这正是NOPASSWORD参数所做的。
我的建议是拥有NOPASSWORD它并对此感到满意。它仍然给人“现在我换系统”的感觉，但它没有烦人的密码。
如果您仍想拥有密码，您可以通过电子邮件将其明文发送，但要求在第一次使用时进行更改。攻击者需要电子邮件和用户的私钥才能成功。如果他们已经可以访问私钥，他们可能会做一些讨厌的事情，.bashrc并在用户下次使用sudo攻击者不需要知道的密码时获得访问权限。
SSH 身份验证和安全权限是两个不同的东西，因此没有必要将其作为默认功能。但是，它又为攻击打开了一个向量（有一个CVE），从我的角度来看，它使用户更容易过度使用它，这很糟糕。
关于密码，一种方法是向用户发送一个短期密码，并要求他/她在首次登录后更改密码。或者允许他们“注册”他们的帐户并且只使用哈希。每种方法都有利有弊，但启发灵感的好地方是商业和免费的 Shell 帐户服务。