I did upgrade on a Fedora Server and was SHOCKED to discover thousands of root attacks on my publicly facing servers and I can't seem to figure out how to stop them!
To be clear; It IS possible to log in to the root account with a password when it should not be possible and the "root attacks" are crackers trying to do just that.
Involved, or possibly involved, Packages are:
Fedora Server 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
... I'm not really sure what the older stuff was, but not older than FC27, that's for sure, and probably a lot younger.
I had been relying upon:
PermitRootLogin prohibit-password
Before that, it was without-password, and both seemed to still work until this change.
Note that the following comment in the default sshd_config file seemed to me to be spurious as the PermitRootLogin parameter was honored, but APPARENTLY it was intended as a warning about UsePAM changing in the future and we should prepare. Well, now - and I'm guessing here! - it has become the actual forced-upon-us setting:
# 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.
PLEASE NOTE the bit about UsePam no not being supported on Fedora!
The result of this change, as stated above, was that now I have root attacks. I am NOT using PAM, and DO NOT WANT to use PAM, so, to use an old-fashioned expression, "this burns my bottom."
However, I TRIED setting the "PAM configuration" I don't even want but it didn't work. I tried this:
UsePAM yes
PasswordAuthentication no
ChallengeResponseAuthentication no
This is exactly what the comment appears to ask us to do, but it doesn't work.
By the way, I DO REQUIRE password authentication for some accounts.
So, I tried an explicit UsePAM no, even though I haven't a clue what "several problems" this "may cause." (Any comments about what those problems are would be very welcome.) However, UsePAM no doesn't work, either!
On the one hand, I can't turn off ssh as this functionality is required, and, by the way, root access is required, too, for some remote backup functionality that spans many accounts, but I also cannot allow a root crack! This is a DISASTER!
Does anyone have a minimalistic PAM setup that can let someone like me keep going without undue delay? ...Or, if I have to go through a full PAM setup, can someone point me to a good tutorial or some such? I really don't have time to learn about a system I don't want!
It might be worth mentioning that other than discussed in this question, there are NO modifications to the sshd configuration from stock OTHER THAN the PermitRootLogin attribute and the three PAM related lines above this that were tried temporarily.
NEW DATA
I discovered that of the many servers I updated last Friday, ONLY ONE of them appears to have this problem! All the rest are on the SAME O/S version.
One key difference I discovered is that on the one that's got the problem, there's NOTHING going into /var/log/secure since the update!
NEW DATA II
It turned out the log file problem was related to SELinux. Once fixed, /var/log/secure was being written to again, but it didn't fix the problem of still being able to log in to root via password when it should not be allowed.
Hmmm...
0 Answers