jldugger Asked: 2009-05-02 17:31:43 +0800 CST2009-05-02 17:31:43 +0800 CST 2009-05-02 17:31:43 +0800 CST 我们应该禁用root用户吗？ 772 我们是否应该删除 root 密码、禁用远程登录并基本上要求管理员使用 sudo 来执行管理操作？ linux security login authentication root 8 个回答 Voted Best Answer C. K. Young 2009-05-02T17:57:27+08:002009-05-02T17:57:27+08:00 我所有的服务器都禁用了 root 帐户（sp_pwdp设置为*）。这是要求sudo所有 root 访问。[1] 这样做的目的是审核所有超级用户的活动，以便人们可以看到对系统做了什么。 对于更核心的选项，您可以sudo写入日志文件（而不是syslog），并使文件仅追加（chattr在 Linux 或chflagsBSD 上使用）。这样，之后没有人可以编辑审计。 [1] 我还有一个不运行 root shell 或从 root 进程执行 shell 转义的策略。（sudo sh -c '...'不过，它可以用于执行管道或重定向。） Mihai Limbăşan 2009-05-03T13:32:02+08:002009-05-03T13:32:02+08:00 我强烈建议不要禁用 root 用户。禁用或限制 root 登录（通过 securetty和通过 sshd_config和通过 PAM以及通过你有什么）如果你的系统允许，限制 root 的权限或拆分 root 角色（类似于RSBAC的做法。）不要通过删除密码来禁用root帐户，否则将无法通过. 在 fsck 报告严重错误的情况下，我知道的所有 initscripts 都会使用它——这意味着如果根文件系统损坏，您将被锁定在系统之外。suloginsulogin 澄清一下：通过“通过删除密码来禁用 root 帐户”，我的意思是各种机制最终以 ! 或 /etc/shadow 的密码字段中的 * 或类似内容。我的意思不是“更改 root 登录机制，以免提示您输入密码”。 Gert M 2009-05-02T21:55:49+08:002009-05-02T21:55:49+08:00 我在所有服务器上都启用了 root 帐户。所有管理员都有自己的用户，并且必须通过该用户登录。从那里他们切换到root。（root ssh 被禁用） 保持低管理员数量。只有在该服务器上真正需要 root 访问权限的人才有密码。 我不是 sudo 的粉丝。只为 root shell 执行“sudo bash”太容易了。我知道这可以被禁用，但为什么要打扰？只需限制可以执行管理员任务并相互交谈的用户。我们确实有一项政策，不允许 root 终端在无人看管的情况下打开。所以它是登录，su，做工作，注销。 注意：我在一家相当小的公司（50 多名员工）工作，我们只有 2 个兼职管理员（1 个 windows/1 个 linux）。当您拥有更多数量级的用户时，这种做事方式可能不是最好的。我个人仍然不会使用 sudo。还有其他方法可以记录根活动。 pablasso 2009-05-30T10:07:50+08:002009-05-30T10:07:50+08:00 我只是禁用了 root 的 SSH 访问，并要求用户（通常只是开发人员）使用 ssh 密钥。字典攻击太多了，更改 SSH 端口对我们来说不是一个选项。 这样您就不必相信任何人有能力编写一个好的密码。一旦进入，只有管理员拥有 sudo 的权限。 Benoit 2009-05-30T09:34:47+08:002009-05-30T09:34:47+08:00 禁用root密码是一个错误的“好主意”。在你需要它的那一天，你将真的需要它。（根据您的配置，您可能需要它以单用户模式登录为例） 禁用 root 远程登录可能是相关的，但前提是您能够在本地登录。 是的，sudo 应该安装在您的每一台服务器上。它很有用且易于配置。你为什么不想使用它？ Mike 2014-10-10T21:10:31+08:002014-10-10T21:10:31+08:00 我知道这个线程真的很老，但链接文章逻辑存在一些重大缺陷，我感觉“咆哮” - sudo 允许列入白名单和列入黑名单。不仅仅是链接文章中指定的黑色 - 这跳过了 AAA（身份验证、授权和审计）的概念 - su 和 sudo 允许分级身份验证和问责制。 场景 1 管理员不小心将一些流氓代码引入系统，以 root 身份登录该代码具有完全访问权限，管理员可能永远不知道发生了什么。至少对于分级登录（例如 su/sudo），如果恶意代码尝试使用提升的权限，系统会提示管理员进行身份验证......如果它没有提升，那么它仅限于用户权限，这应该会导致最小的损害。 场景 2 流氓管理员想要获取信息/进行更改。他们连接到控制台（物理控制台访问、HP iLo/类似或 vGuest 控制台访问），以 root 身份登录并做任何他们想做的事情。除非有用于获得控制台访问权限的指定帐户/访问卡，否则可能没有太多的审计线索。 确保他们真的是他们所说的那样。身份盗窃不是问题，身份验证才是问题。 检查他们的授权，只给他们当时需要的东西。分级授权允许他们在需要时提升。 审核所有内容，做好记录，让您知道谁、做了什么、何时何地。最好也是为什么 carlito 2009-05-24T15:53:46+08:002009-05-24T15:53:46+08:00 您应该要求每个人都对每个根命令使用 sudo 作为策略。从来没有理由运行“sudo bash”或类似的东西，这只是为了方便，由于无知，或掩盖自己的踪迹。 如果您直接禁用对 root 帐户的登录，则会削弱您在出现严重问题时修复系统的能力。 如果您无法说服您的管理员以自己的身份登录并为以 root 身份运行的每个命令运行 sudo，并且不能将其拆分为 shell，那么您将遇到没有技术解决方案的严重问题。 imz -- Ivan Zakharyaschev 2011-05-21T21:03:40+08:002011-05-21T21:03:40+08:00 Owl secure distribuion 的作者（和 Solar 设计师）有一个相反的、经过仔细论证的观点；例如，请参阅答案https://unix.stackexchange.com/questions/8581/which-is-the-safest-way-to-get-root-privileges-sudo-su-or-login/8660#8660陈述他们的主张。他们的观点也解决了审核超级用户操作（谁做了什么）的问题（基本上，解决方案是拥有多个不同名称的 root 用户）。
我所有的服务器都禁用了 root 帐户（
sp_pwdp设置为*）。这是要求sudo所有 root 访问。[1] 这样做的目的是审核所有超级用户的活动，以便人们可以看到对系统做了什么。对于更核心的选项，您可以
sudo写入日志文件（而不是syslog），并使文件仅追加（chattr在 Linux 或chflagsBSD 上使用）。这样，之后没有人可以编辑审计。[1] 我还有一个不运行 root shell 或从 root 进程执行 shell 转义的策略。（
sudo sh -c '...'不过，它可以用于执行管道或重定向。）我强烈建议不要禁用 root 用户。禁用或限制 root 登录（通过 securetty和通过 sshd_config和通过 PAM以及通过你有什么）如果你的系统允许，限制 root 的权限或拆分 root 角色（类似于RSBAC的做法。）不要通过删除密码来禁用root帐户，否则将无法通过. 在 fsck 报告严重错误的情况下，我知道的所有 initscripts 都会使用它——这意味着如果根文件系统损坏，您将被锁定在系统之外。
suloginsulogin澄清一下：通过“通过删除密码来禁用 root 帐户”，我的意思是各种机制最终以 ! 或 /etc/shadow 的密码字段中的 * 或类似内容。我的意思不是“更改 root 登录机制，以免提示您输入密码”。
我在所有服务器上都启用了 root 帐户。所有管理员都有自己的用户，并且必须通过该用户登录。从那里他们切换到root。（root ssh 被禁用）
保持低管理员数量。只有在该服务器上真正需要 root 访问权限的人才有密码。
我不是 sudo 的粉丝。只为 root shell 执行“sudo bash”太容易了。我知道这可以被禁用，但为什么要打扰？只需限制可以执行管理员任务并相互交谈的用户。我们确实有一项政策，不允许 root 终端在无人看管的情况下打开。所以它是登录，su，做工作，注销。
注意：我在一家相当小的公司（50 多名员工）工作，我们只有 2 个兼职管理员（1 个 windows/1 个 linux）。当您拥有更多数量级的用户时，这种做事方式可能不是最好的。我个人仍然不会使用 sudo。还有其他方法可以记录根活动。
我只是禁用了 root 的 SSH 访问，并要求用户（通常只是开发人员）使用 ssh 密钥。字典攻击太多了，更改 SSH 端口对我们来说不是一个选项。
这样您就不必相信任何人有能力编写一个好的密码。一旦进入，只有管理员拥有 sudo 的权限。
禁用root密码是一个错误的“好主意”。在你需要它的那一天，你将真的需要它。（根据您的配置，您可能需要它以单用户模式登录为例）
禁用 root 远程登录可能是相关的，但前提是您能够在本地登录。
是的，sudo 应该安装在您的每一台服务器上。它很有用且易于配置。你为什么不想使用它？
我知道这个线程真的很老，但链接文章逻辑存在一些重大缺陷，我感觉“咆哮” - sudo 允许列入白名单和列入黑名单。不仅仅是链接文章中指定的黑色 - 这跳过了 AAA（身份验证、授权和审计）的概念 - su 和 sudo 允许分级身份验证和问责制。
场景 1 管理员不小心将一些流氓代码引入系统，以 root 身份登录该代码具有完全访问权限，管理员可能永远不知道发生了什么。至少对于分级登录（例如 su/sudo），如果恶意代码尝试使用提升的权限，系统会提示管理员进行身份验证......如果它没有提升，那么它仅限于用户权限，这应该会导致最小的损害。
场景 2 流氓管理员想要获取信息/进行更改。他们连接到控制台（物理控制台访问、HP iLo/类似或 vGuest 控制台访问），以 root 身份登录并做任何他们想做的事情。除非有用于获得控制台访问权限的指定帐户/访问卡，否则可能没有太多的审计线索。
您应该要求每个人都对每个根命令使用 sudo 作为策略。从来没有理由运行“sudo bash”或类似的东西，这只是为了方便，由于无知，或掩盖自己的踪迹。
如果您直接禁用对 root 帐户的登录，则会削弱您在出现严重问题时修复系统的能力。
如果您无法说服您的管理员以自己的身份登录并为以 root 身份运行的每个命令运行 sudo，并且不能将其拆分为 shell，那么您将遇到没有技术解决方案的严重问题。
Owl secure distribuion 的作者（和 Solar 设计师）有一个相反的、经过仔细论证的观点；例如，请参阅答案https://unix.stackexchange.com/questions/8581/which-is-the-safest-way-to-get-root-privileges-sudo-su-or-login/8660#8660陈述他们的主张。他们的观点也解决了审核超级用户操作（谁做了什么）的问题（基本上，解决方案是拥有多个不同名称的 root 用户）。