[samlinnfer]

24.04 also ships with a footgun that keeps PasswordAuthentication enabled even if you edit /etc/ssh/sshd_config. It adds a /etc/ssh/sshd_config.d/50-cloud-init.conf that force overrides any PasswordAuthentication settings you have configured in /etc/ssh/sshd_config.

See here: https://news.ycombinator.com/item?id=42133181

[HumanOstrich]

A better practice is to use the `.d/` convention as intended - so you can have overrides and customizations without having to edit the OS-managed /etc/ssh/sshd_config file and fight it if an OS upgrade changes it.

Edit: It's not really a mistake on Ubuntu's part, and is common in other distros for overriding upstream defaults[1].

[1]: https://askubuntu.com/a/1516347

[Fire-Dragon-DoL]

There is a bug with that where you cannot "redefine" the ftp command used (I think it was that, or the group declaration), so in the end I had to edit the configuration manually either way

[homebrewer]

The proposed solution is bad, the file will be restored by the package manager at some point. Always prefix your override files with '99-' or 'zz-', this would have prevented the problem.

[wahern]

For OpenSSH configuration the first directive controls, not the last. So if you want to set an option make sure your include filename comes lexically earlier, not later. This is why the Include directive is at the top of distro-installed /etc/ssh/sshd_config. You can verify your server configuration using `sshd -T`, and a client configuration using `ssh -G`; they dump the resolved configuration to stdout.

[SoftTalker]

I don't have /etc/ssh/sshd_config.d/50-cloud-init.conf on my ubuntu 24.04 machines. What creates it? Is it a clean-install vs. upgrade difference perhaps?

[vbezhenar]

This file is created when the server is provisioned with cloud-init. For example when you use https://cloud-images.ubuntu.com/ as a template image to create your VM. For these cases you would need to supply cloud-init config via separate means (openstack user-data or just secondary mounted ISO) and cloud-init would perform post-install tasks like configuring users, passwords, ssh keys, etc. If you just install your machine from ISO, cloud-init is not used.

I guess that many hosters will use cloud-init for their VPS offerings "under-the-hood". Usually they'll generate password and mail it to you, so obviously ssh password should be allowed for this case.

[HumanOstrich]

Unfortunately, one possibility is the user chose "enable SSH password authentication" during the install [1]. Or it's a cloud instance from a provider that provisions instances with a password.

[1]: https://askubuntu.com/a/1440509

[d0mine]

It is Ubuntu issue, it is cloud-init issue. You can get the same result on other distros provisioned by cloud-init.

[MortyWaves]

Now I definitely feel glad that I decided on moving back to Debian for servers.

[vbezhenar]

It works identically for debian. Just today I configured debian server with cloud-init and it created absolutely the same file.

[gazunklenut]

Pretty sure this exists on Debian too

[yjftsjthsd-h]

I believe I've seen cloud vendors configure out that way, but I don't think it's an actual Debian default.

[MrResearcher]

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.

[poizan42]

Nope, not on my system: https://i.imgur.com/1qCLXXZ.png

[HumanOstrich]

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.

[normie3000]

What does .d imply?

[HumanOstrich]

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.

[HumanOstrich]

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.

[Brian_K_White]

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.

[HumanOstrich]

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.

[DaSHacka]

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.

[HumanOstrich]

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.

[1]: https://askubuntu.com/a/1440509

[amelius]

Does anyone know how to turn off auto updates on Ubuntu 22?

I thought I fixed it, but apparently not. It is driving me crazy.

[HumanOstrich]

Hey I think you might have replied to the wrong thread or post. This thread/post has nothing to do with Ubuntu 22 updates.

[charliebwrites]

Is this true for Ubuntu Server 24 as well?

Was thinking of upgrading but not if I can’t configure SSH to be key only

[HumanOstrich]

There is nothing broken with Ubuntu, just people not understanding how configuration files work in Linux, choosing to enable password auth in SSH during installation, or using a cloud provider that provisions instances with passwords and overrides the default.

[lathiat]

You can still configure it to be key only, you just need to put your own override as a file in /etc/ssh/sshd_config.d/ rather than /etc/ssh/sshd_config. The files are read ins order, so your filename needs to sort after the 50-cloud-init.conf file.

This would work: echo "PasswordAuthentication no" > /etc/ssh/sshd_config.d/60-password-auth.conf

[speleding]

With sshd configuration the first option is the one that sticks, so you need to make sure it sorts BEFORE the 50-cloud-init.conf file.

[yrro]

Am I crazy or have people lost the ability to read documentation?

[yrro]

(specifically <https://cloudinit.readthedocs.io/en/latest/reference/modules...>)

[xarope]

omg I just disabled this on a major server that was just upgraded to 24.04.

Had to check my other VMs. Luckily most of them are debian or 22.04 (for now).