4 ms·

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

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.

DaSHacka 2y ago
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.
- deleted 2y ago
  [deleted]
- HumanOstrich 2y ago
  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 https://askubuntu.com/a/1440509
Brian_K_White 2y ago
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 2y ago
  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.
  - Brian_K_White 2y ago
    [flagged]
    - HumanOstrich 2y ago
      Child? Do you condescend based on principle or dogma? ¯\_(ツ)_/¯
      - Brian_K_White 2y ago
        [flagged]
        HumanOstrich 2y ago
        There isn't a comment specifically saying that including more config files can override values, so I'll give you that. However, it does have comments explaining exactly how to override default values. It looks like what the OP of this thread is attempting should work unless they messed up something else. I'm looking at a couple sshd_config files on my servers, and the Include directive for the overrides is the first non-comment line in the file. Having that Include be first means that changing any settings in the sshd_config file will override anything set by sshd_config.d/* files. What in the heck are these people doing to break their config? There really is no legitimate issue here.

DaSHacka 2y ago

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.

deleted 2y ago
[deleted]
HumanOstrich 2y ago
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 https://askubuntu.com/a/1440509

Brian_K_White 2y ago

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 2y ago
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.
- Brian_K_White 2y ago
  [flagged]
  - HumanOstrich 2y ago
    Child? Do you condescend based on principle or dogma? ¯\_(ツ)_/¯
    - Brian_K_White 2y ago
      [flagged]
      - HumanOstrich 2y ago
        There isn't a comment specifically saying that including more config files can override values, so I'll give you that. However, it does have comments explaining exactly how to override default values. It looks like what the OP of this thread is attempting should work unless they messed up something else. I'm looking at a couple sshd_config files on my servers, and the Include directive for the overrides is the first non-comment line in the file. Having that Include be first means that changing any settings in the sshd_config file will override anything set by sshd_config.d/* files. What in the heck are these people doing to break their config? There really is no legitimate issue here.