So, I found the problem.
It seems to be indeed a configuration problem.
If the sshd_config contains the directive UsePAM no
then the ssh daemon doesn't accept the user key and ask for a password.
With UsePAM yes
the login via keys is working in all cases (SELINUX permissive or enforced, user account locked or not)
tl;dr: Everything came down to an invalid value for SELINUXTYPE
.
Make sure SELINUXTYPE
has a valid value, then perform relabelling if needed (e.g. if you've booted with SELinux off during your diagnostics), reboot and crack open the champagne.
For some reason, and at some point in time, /etc/selinux/config
had acquired the setting SELINUXTYPE=permissive
.
This is not a valid option for that parameter, and it appears to make the value fall back on the value "default", based upon the reason listed for why Dbus, Login Service and Authorization Manager failed:
Failed to open "/etc/selinux/default/contexts/dbus_contexts": No such file or directory
This is troublesome because there is no selinux-policy-default
package in CentOS 7 (on Debian, for example, it was deliberately removed in Jessie so I'd imagine the same is true here).
I suspect this is also why attempts to relabel the file system using restorecon
(from single-user mode, and from a shell reached by init=/sbin/sh
) resulted in baffling "No such file or directory" outputs, and getenforce
would still show "Disabled" for no evident reason.
To switch to the selinux-policy-targeted
stuff which is installed, I fixed the configuration to be SELINUXTYPE=targeted
(as I believe it should have been all along), then again rebooted with enforcing=0 autorelabel=1
.
The relabelling then took place. Following that, the system booted up as normal.
Best Answer
Per the documentation:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/using_selinux/changing-selinux-states-and-modes_using-selinux
Also see
/etc/selinux/config