Failed to start OpenSSH server daemon loop preventing boot Centos 8

Question

I attempted to allow a usergroup "students" to use password log in over ssh by adding the lines:

Match Group students
    PasswordAuthentication yes

to the end of my /etc/ssh/sshd_config file.

Then, as the server had been up for 3 weeks or so I decided to run a full yum update and reboot the system.

From this point on it has failed to boot.

While booting, I see a spinning circle of lines for a while, then a cut to a black screen with a grey bar on the left where the process hangs.

Hitting ctrl-alt-F2 I see a looping

A start job is running for Hold until boot process finishes up (x/no limit)

After a while this reports:

[FAILED] Failed to start OpenSSH server daemon.

and the loop begins again. See image for full example.

I booted into single user mode and reverted my changes to the config file, the same problem occurs.

(To reduce possible errors I have connected the monitor to the onboard graphics, rather than the nVidea GPU as I suspect there may also be a problem with the GPU drivers caused by the update as connected to the GPU I instead hit an "oops a problem has occurred screen".)

UPDATE:

It turned out that SELinux was preventing sshd from reading sshd_config, causing the loop. Running restorecon on sshd_config failed to fix the problem, so I disabled SELinux.

Now the boot process hangs on a single never ending start job when booting into Runlevel 5. I suspect this is to do with the GPU drivers as the system still crashes with an "oops" screen when the monitor is connected to the GPU, integrated graphics make more progress.

Here I have run out of time to fix the problem. As this machine exists as a headless compute server I am just booting into Runlevel 3, which seems to run fine. I re-installed the newest nVidea drivers to no change.

Even the programs that require CUDA appear to be running correctly, so I am calling this good enough in the absence of any further advice from the community.

Answer 1

I suggest booting into recovery more to

1. Revert changes
2. Examining sshd log files to see what the issue might be

Hitting control + alt + del while the system is booting should cause it to reboot gracefully as systemd should trap that keyboard keystroke.

Answer 2

Please see the comments to Rouben Tchakhmakhtchian's answer for the trail I followed to get here, and see my update to the question for more detail.

The problem ended up being down to SELinux preventing sshd from being able to read sshd_conf. Despite all my attempts to reset the permissions and allow the read, I was never successful.

In the interests of "time is money" I disabled SELinux instead. Now sshd can read sshd_conf correctly, so the machine boots to multi-user mode just fine, and one can login remotely over ssh.

I never managed to fix booting into a desktop environment. I think the problem here is unrelated though. As this machine is a headless research server, I never dug any further into that.