9

I was setting up an ubuntu server and, like 99% of all people, one of the first things I do is to disable password authentication in favor of keys.

On other distros and in other times this is done by merely editing /etc/ssh/sshd_conf and making sure that...

PasswordAuthentication no
ChallengeResponseAuthentication no
UsePam no

As you may already know, just doing that no longer works because near the beginning, the sshd_conf file includes ANOTHER conf file with...

Include /etc/ssh/sshd_config.d/*.conf

The file included is something named 50-cloud-init.conf whose sole contents upon installation happens to be...

PasswordAuthentication yes

Conf files that are included from sshd_conf.d override the original sshd_conf so if one were to just change sshd_conf, 50-cloud-init.conf would then flip back the password authentication setting. Changing it to 'no' will finally disable password logins.

I've done this twice and have forgotten about it each time. I will remember now, but it bugs me because I can't fathom what the rationale is for this stuff.

Searching around, so far, has yielded not much in terms of "why". Mostly folks are just happy to overcome this little obstacle and move on. I am glad it's resolvable but I got questions:

  • The name of this extra conf file suggests it's something to do with cloud-based installations. But what cloud? I installed this on a physical machine. Presumably cloud-init has created this for me, but why? I am not running in a cloud environment. Also, what's "50"? 50 what? Moreover, the ONLY line that it has enables password auth. In cloud installations doesn't everyone always use keys anyway?

  • I see that it's possible to just remove cloud-init for non-cloud installs. Are there any caveats to doing that? It seems weird that this would be installed and running by default EVEN on non-cloud installations. There must be a reason for it, right?

Angelo
  • 889

1 Answers1

14

It might help you understand things faster if you move past the "cloud" in "cloud-init": it's a tool for declaratively configuring systems, usually used for first-time setup of various sort (e.g., as part of a desktop installer, or virtual instances in cloud environments, or other such places where installers aren't present, such as Raspberry Pi images). It was originally created for cloud environments, yes, but it has since grown greatly in scope and features. In particular, it is used by the Ubuntu desktop installer for various initial configuration activities, which is what you see here. This makes a lot of sense from code-reuse perspective: there's no particular reason for the desktop installer to reinvent the wheel for doing these things when a dedicated, well-maintained, widely-used tool exists.

As for the extra file you're seeing, the reason for that is mainly the same as what I describe in my answer to Is there a reason sysctl is broken into so many configuration files?:

Modifying configuration transactionally is easiest when you can just add or remove a file with the exact contents you want, instead of using regexes or whatever to modify a line in the middle of a configuration file filled with who-knows-what. That is why directories allowing drop-in configuration files are highly preferable to single configuration files.

Typically software supporting such drop-in configuration files read files in lexicographical order from a directory or set of directories. To make the lexicographical ordering easier to understand, there's a long standing convention to use zero-padded two-digit prefixes (00-foo.conf, 50-whatever.sh, etc.) since these prefixes sort the same numerically and lexicographically. If you have a file NN-whatever containing some setting that you want to override, you have two options:

  1. Simply overwrite that file with whatever you want. If the file in question has, or could have, other settings that you don't wish to override and don't wish to keep track of, you might want to avoid this option.

  2. Create a file MM-whatever, where MM is:

    • less than NN if the software prioritizes the first appearance of a setting (say 00 in the extreme), or,
    • greater than NN if it prioritises the last appearance of a setting (say, 99 in the extreme).

For a two-digit prefix, the extremes are 00 and 99, 50 is right around the middle. So it's easy for an administrator to override it. In your particular case, just create a file /etc/ssh/sshd_config.d/00-only-pubkey-auth.conf containing:

PasswordAuthentication no
ChallengeResponseAuthentication no
UsePam no

And you don't have to bother about the main config file or the other drop-in files.

This particular change isn't even specific to Ubuntu or cloud-init. When sshd first started supporting drop-in configuration files, Arch Linux also immediately moved to using a drop-in file (named differently, of course) for their changes to the upstream defaults. And I, too, immediately made another drop-in file overriding these settings. Before this, I had to edit the main config file itself, and the package management system would then ask me to check changes every time the config file was updated in the package. These days, I haven't been pestered about this particular configuration change in a while, making my life easier in the long run.

muru
  • 207,228