Your config is not what is running
In a stock SSH configuration the password authentication line is commented out. Reading the file, it looks disabled. It is not: a commented line means the compiled-in default applies, and that default is on. Asking the daemon for its effective configuration prints what it will actually enforce, which is also where you find that the effective setting name does not always match the one documented in the file. Verify hardening against the running service, never against the file you edited.
The line is commented out, so password logins must be off. They are not.
You harden a server by editing a config file. Then you read the file back to check, and it agrees with you, because you wrote it.
Here is the stock SSH configuration. The password setting is there, with a comment marker in front of it. Read that quickly and you conclude it is off.
A comment marker does not disable a setting. It leaves the built-in default in charge, and that default is invisible in the file.
So ask the service instead. One flag prints what it will actually enforce, after defaults and includes resolve. Password logins: on.
Look at the root login line too. The effective name is not even the word the file uses.
The file records your intention. The daemon holds the outcome, and only one of them is what an attacker meets.
Verify hardening against the daemon, not the file.
#linux#security#selfhosted#infosec#sysadmin
❯ Verify hardening against the daemon, not the file.