我确实在 Fedora 服务器上进行了升级，并震惊地发现我的公开服务器遭受了数千次根攻击，我似乎不知道如何阻止它们！
要明确的是，虽然不可能，但确实可以使用密码登录 root 帐户，而“root 攻击”正是破解者试图这样做的。
涉及或可能涉及的软件包包括：
Fedora 服务器 32 openssh-server-8.3p1-3.fc32.x86_64 pam-1.3.1-26.fc32.x86_64 fprintd-pam-1.90.1-1.fc32.x86_64 pam_afs_session-2.6-12.fc32.x86_64 gnome-keyring-pam-3.36.0-1.fc32.x86_64 systemd-pam-245.8-2.fc32.x86_64 pam_passwdqc-1.4.0-1.fc32.x86_64
... 我不太确定最老的东西是什么，但肯定不会比 FC27 老，而且可能要年轻得多。
我一直依赖：
PermitRootLogin prohibit-password
在此之前，情况是这样的without-password，而且在发生这一变化之前，两者似乎都仍然有效。
请注意，默认文件中的以下注释sshd_config在我看来是虚假的，因为该PermitRootLogin参数是有效的，但显然它旨在警告我们UsePAM未来可能会发生更改，我们应该做好准备。好吧，现在 -我猜是这样的！- 它已成为实际强加给我们的设置：
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
# WARNING: 'UsePAM no' is not supported in Fedora and may cause several
# problems.
UsePam no请注意Fedora 不支持这一点！
如上所述，这一变化的结果是，我现在遭受了 root 攻击。我没有使用 PAM，也不想使用 PAM，所以，用一句老话来说，“这真是让我痛心不已。”
但是，我尝试设置我根本不想要的“PAM 配置”，但没有成功。我尝试了这个：
UsePAM yes
PasswordAuthentication no
ChallengeResponseAuthentication no
这正是评论要求我们做的，但它不起作用。
顺便说一句，我确实要求某些帐户进行密码验证。
因此，我尝试了一个明确的UsePAM no，尽管我不知道这“可能导致”什么“几个问题”。 （任何关于这些问题的评论都非常受欢迎。）但是，UsePAM no也不起作用！
一方面，我无法关闭 ssh，因为此功能是必需的，顺便说一句，对于跨多个帐户的某些远程备份功能，也需要 root 访问权限，但我也不能允许 root 破解！这是一场灾难！
有没有人有一套简单的 PAM 设置，可以让像我这样的人继续使用而不会出现不必要的延迟？...或者，如果我必须完成完整的 PAM 设置，有人能给我提供一份好的教程或类似的东西吗？我真的没有时间去学习我不想要的系统！
也许值得一提的是，除了在这个问题中讨论之外，sshd除了PermitRootLogin属性和上面临时尝试的三个 PAM 相关行之外，对库存配置没有任何修改。
新数据
我发现，上周五更新的众多服务器中，只有一个似乎有这个问题！其余的服务器都使用相同的操作系统版本。
/var/log/secure我发现的一个主要区别是，在出现问题的地方，自更新以来什么都没有发生！
新数据二期
事实证明日志文件问题与有关SELinux。修复后，/var/log/secure再次被写入，但这并没有解决仍然能够通过密码登录 root 的问题，而这是不应该允许的。
嗯……