Damn, you really got me scared there for a second. Just re-checked by Debian 12 systems on AWS, I don't have any files residing in *.d directories. So I confirm that if you used the official AWS Debian image, you wouldn't get it.
And if you downloaded and installed the authentic Debian 12 image from debian.org, you don't get it either. Must be a Ubuntu thingy.
Great, now you can start putting your customizations in that directory instead of the OS-managed /etc/ssh/sshd_config blob. That's why the `.d/` convention exists.
I had to look up the info because I wasn't sure really, so I appreciate the direct question. It means 'directory' or 'conf.d pattern'. So you have your config file, and the config directory that contains "parts" of the config to be merged with the main one to provide customizations/overrides.
Err, why? Nothing is actually broken with Ubuntu 24.04. The issue GP is describing is just a lack of understanding of how config files have worked on Linux for decades.
On top of that, this issue doesn't even "ship with 24.04". GP probably chose to enable password auth in SSH during installation, or they used a cloud provider that provisions instances with passwords and overrides the default.
Actually ubuntu and/or some cloud integrator is violating principle of least suprise, which predates by even more decades and applies everywhere not just in a computer operating system.
Having /etc/ssh/sshd_config not do what it appears to do is inexcusable, however that comes about.
Even if the fix is no more than structuring the file a little differently so there are parts both before and after the .d loading, and comments that say what overrides what, and all the actual config files and default behavior are still the same.
That's just not how it works, and it never has. One of the main purposes of the .d files is to avoid modifying the distro's sshd_config file, so you don't have to resolve conflicts during an OS upgrade. Commenting your overrides in the sshd_config? That's backwards.
Downstream distros sometimes want to override the default settings. That's what .d is for. It doesn't violate the dogma "principle of least surprise", especially if you run `man sshd_config` and learn the first thing about sshd's config files.
Any sufficiently poorly constructed system is indistinguishable from a legitimate vulnerability.
You shouldn't need to edit an undocumented file that's force enabling an insecure authentication method in the first place.
"You're using it wrong" doesn't change the fact that the defaults are poor and likely to ultimately cause more devices to be improperly configured than if it was left as sysadmins and end-users expect.
They likely chose the option to enable password-based SSH authentication during installation [1], or it's a cloud service that provisions servers with a password.
I've been looking for info about whether it's force-enabled with a vanilla install where the user doesn't actually choose for it to be enabled. I'm happy to be educated here.
