The order of files in /etc/ssh/sshd_config.d/ matters

The way you wrote the rule makes no sense to me. Maybe it's too early in the day for me?

"In placing configuration files higher than user-defined configuration but Only with SSH client, can want..."

I find this SSHD snippet to be extremely useful in enterprise network, notably with OpenLDAP.

Also the most dangerous but flexible way to authenticate a user.

https://jpmens.net/2019/03/02/sshd-and-authorizedkeyscommand...

For those that are exploring software-based public certificate and OpenSSH, Ive broken down the settings for most PKI handlers.

https://egbert.net/blog/articles/openssh-file-authorized_key...

This comment seems to have a lot to say but it was word salad to me, quite confusing and hard to read :(

You mean there are consequences to making assumptions? ;) (also old sysadmin)

I've never liked the directory.d/* infrastructure. In so many cases, even with a properly configured sshd_config, the resulting configuration file is not so large that it benefits from being split up.

You have to deal with ordering issues, symlink management in some cases, and unless the "namespace" of sorting number prefixes is strictly defined, it's never something that's convenient or durable to "patch" new files into. The proliferation of 99_* files shows the anti-utility this actually provides.

I much prefer configuration files with a basic "include" or "include directory" configuration item. Then I can scope and scale the configuration in ways that are useful to me and not some fragile distribution oriented mechanism. Aside from that with xz I don't think I want my configurations "patchable" in this way.

The SSHD internally has a config structure. Initially, it's all initialized with -1 for flags/numbers/timeouts, and with NULL for strings. When an option is parsed, there is a check whether the config structure's corresponding field is -1/NULL (depending on the type) before the parsed value is saved.

Another program with first-wins I've seen used dict/map for its config so the check was even simpler: "if optname not in config: config[optname] = parsed_value".

It probably makes a bit more sense when you think about the fact that SSH frequently does a "try to match this host against a list of configured host-patterns" operation. In that case, "first match" is the obvious thing to do.

iptables uses first-wins.

https://serverfault.com/questions/367085/iptables-first-matc...

It's actually the simplest scheme. Reparse from the top whenever you need to query a setting. When you see one, exit. No need to even bother to store an intermediate representation. No idea if this matches the actual ssh implementation, but that's the way many historical parsers worked. The idea of cooking your text file on disk (into precious RAM!) is fairly modern.

Except that doesn't tell you what it's doing, that tells you what it _might_ do, if you (re)start the server.

sshd -T reads the configuration file and prints information. It doesn't print what the server's currently-running configuration is: https://joshua.hu/sshd-backdoor-and-configuration-parsing

Yes. Run this as a validation step during base os image creation, if such image is intended to start system with sshd. That way you can verify that distro you use did not pull the carpet from under your feet by changing something with base sshd config that you implicitly rely on.

I think their surprise comes from earlier config wins conflicts, rather than the other way around. That's not reflected in the title.

I initially read "the order of files in /etc/ssh/sshd_config.d/" to mean the order of files in the underlying directory inode, i.e. as returned by `ls -f` — and thought, "oh god"... But the lexicographical order, that's not too surprising.

yeah, this is confdir 101...

but i guess learning is better late than never type of thing.

also what confuses people more on this is that openssh is properly designed, so configs are first seen wins. exactly so that file 0_ wins from 99_... but most people see badly designed software where 99_ overrides 0_. openssh way is exactly so it works best with confir or ssh/options where it matches by hosts and you can place the more important stuff first without fear defaults will override it.

Gentoo started doing this last year and I absolutely hate it.

It might not be an OpenBSD thing. It may be a Debian/ubuntu-ism.

A lot of software which reads drop-in files will load them in numerical (or indeed alphabetical) order. Obviously this is important if the order your config files are loaded in matters, but otherwise it's just become a convention so people do it even if the load order doesn't actually matter.

Typically, config files are merged into one by loading them like ./conf.d/*, the order being determined alphabetically from their file names. You do not need to use numbers but they help to see that order.

In this particular case cloudinit presence in the story is incidental, delivery mechanism of said config file could have been different.

It's useful for initializing state that could not have been initialized before booting in the target environment. Canonical example, I guess, being ssh server and client keys management, but the list of modules it implements is long.

Provides a moderately-configured starting point for new cloud VM deployments without requiring custom images

> Nobody ever said "we don't need worry about that, cloudinit takes care of it".

Well, why would it come up? You don't need to worry about things you don't need to worry about.