The order of files in /etc./SSH/sshd_config.d/ matters (and may surprise you)

Summary

Suppose, not entirely hypothetically, that you have an Ubuntu 24.04 server system where you want to disable SSH passwords for the Internet but allow them for your local LAN. This looks straightforward based on sshd_config, given the PasswordAuthentication and Match directives: PasswordAuthentication no Match 127.0.0.0/8,192.168.0.0/16 PasswordAuthentication yes Since I'm an innocent person, I put this in a file in /etc/ssh/sshd_config.d/ with a nice high ordering number, say '60-no-passwords.conf'. Then I restarted the SSH daemon and was rather confused when it didn't work (and I wound up resorting to manipulating AuthenticationMethods, which also works). The culprit is two things combined together. The first is this sentence at the start of sshd_config: [...] Unless noted otherwise, for each keyword, the first obtained value will be used. [...] Some configuration systems are 'first mention wins', but I think it's more common to be either 'last mention wins' or 'if it's mentioned more than once, it's an error'. Certainly I was vaguely expecting sshd_config and the files in sshd_config.d to be 'last mention wins', because that would be the obvious way to let you easily override things specified in sshd_config itself. But OpenSSH doesn't work this way. (You can still override things in sshd_config, because the global sshd_config includes all of sshd_config.d/* at the start, before it sets anything, rather than at the end, how you often see this.) The second culprit is that at least in our environment, Ubuntu 24.04 writes out a '50-cloud-init.conf' file that contains one deadly (for this) line: PasswordAuthentication yes Since '50-cloud-init.conf' was read by sshd before my '60-no-passwords.conf', it forced password authentication to be on. My new configuration file was more or less silently ignored. Renaming my configuration file to be '10-no-passwords.conf' fixed my problem and made things work like I expected.