Answers:
在大多数情况下，实际上禁用远程root登录几乎无济于事。它在一定程度上有助于实施一项策略，使管理员可以通过自己的帐户登录并su根据需要进行root（或sudo与sudosh... 一起使用，具体取决于您的策略）。
创建非常长且麻烦的根密码（只要您仍然不使用古老的DES + 12位盐哈希作为密码，就可以生效）在执行这种策略方面同样有效。
我熟悉的一个站点拥有一个系统，通过该系统，将为每个主机随机生成唯一的密码，并将其存储在数据库中，然后推送到系统中。要求管理员使用ssh其普通帐户sudo进行大多数操作。但是，他们可以通过基于SSL的内部Web服务访问根密码（这进一步需要其RSA SecurID令牌和PIN）。提取根密码需要输入理由（通常是指向Remedy™凭单号码的链接）并在定期审核的地方访问。直接使用root密码的少数可接受原因之一是在fsck引导过程中系统被停止的情况下...sulogin要求使用真实的root密码才能手动运行文件系统检查和修复过程。（已经讨论了关于此方法的其他方法---在Linux上相对容易，但是在尝试扩展过程以解决许多旧的HP-UX，AIX以及较旧的SunOS和Solaris系统时就变得困难得多。仍在那种环境中生产）。
在某些极端情况下，需要root密码-或至少是最佳的替代密码。通常，最好的策略是在保持可用状态的同时，使其足够强大，以应对各种可能遇到的威胁。
我知道的另一个站点采用了相当优雅的方法来进行分散帐户管理。它们具有user- *和sudo- *软件包（认为是RPM），它们使用常规的软件包管理过程和自动化基础结构安装到系统中。在他们的情况下，sudo- *软件包依赖于相应的user- *软件包。这很好，因为它使您可以拥有具有本地化帐户的计算机集群（所有帐户均为管理员，开发人员，支持人员或“无头”帐户），并且消除了对LDAP / NIS或其他网络身份和身份验证服务的依赖。（这减少了系统之间的耦合，使它们明显更坚固）。
我认为我喜欢这种方法是因为它具有灵活性。具有sudo访问权限的任何人都可以发出命令以添加普通用户或另一个sudo用户帐户。因此，如果我正在处理票证，那么已经可以访问系统的任何人都可以轻松地给我访问权限。毫无疑问，将我添加到某些中央数据库中某些访问控制列表的票证通过一些集中批准过程最终将更改传播回所讨论的系统。sudo系统上的任何授权用户都可以给我访问权限，以后再将我删除。（是的，如果我是邪恶的，他们会游戏我sudo我可能会恶意修改某些内容以保留访问权限……实际上，就像普通用户一样，我可以做一些事情来保留此类删除操作之后的访问权限。但是，这不是他们担心的威胁。我的访问权限仍然仅限于相对较少的整体系统；因此，与我见过的大多数类似方案相比，被盗用帐户的影响仍然有限。
如果禁用远程root用户访问权限，则可以防止远程攻击者直接获取root用户-他们必须断开另一个帐户，获得对计算机的访问权限，然后尝试获得对root用户的访问权限。这是一个额外的步骤。
通常，禁用root进行远程访问。SU运作良好。如果确实发生故障，则始终可以直接访问该框进行修复。
如果您想更严格-完全禁用root，那就是sudo的目的。同样，通过这种方法，您仍然可以通过进入单用户模式（例如Ubuntu）来获得root用户访问权限。虽然，据我的文档，我相信他们为此使用了修补的init。
此外，您可以设置空闲状态以启动空闲的用户，以防其终端保持打开状态，并且PC也处于打开状态。您可以强制所有用户使用密钥，但是密钥管理可能很困难。
单个传递日志记录主机作为防漏玻璃类型的系统也强制了附加的保护层和审核跟踪。
我建议您将系统设置为仅允许在控制台进行root访问。
否则，将sudo与password选项一起使用，允许选定的用户访问priv'd命令。顺便说一句，认识到sudo可以设计为将用户帐户限制为某些命令。Sudo在系统日志中留下一个已使用的“标记”。sudo比su更好，因为不会公开root密码。因此，您可以更改root密码，并且使用sudo的用户不会更明智。
允许使用sudo来获取priv'd命令时，应随时间强制更改密码，具体频率取决于环境。
永远不允许root
设置系统以仅允许通过键访问而无需密码
然后为允许通过root帐户进行更改的用户设置sudo