| View previous topic :: View next topic |
| Author |
Message |
freke
Veteran
Joined: 23 Jan 2003
Posts: 1050
Location: Somewhere in Denmark
|
 Posted: Sat May 13, 2023 11:31 am Post subject: SSH config-changes |
 |
|
| Quote: | 2023-05-11-openssh
Title OpenSSH directory configuration changes
Author Sam James <sam@gentoo.org>
Posted 2023-05-11
Revision 1
Gentoo's OpenSSH package will start using the /etc/ssh/sshd_config.d
and /etc/ssh/ssh_config.d directories for both Gentoo default settings
and use by the administrator.
The default /etc/ssh/sshd_config and /etc/ssh/ssh_config files will
respectively include configuration files in /etc/ssh/sshd_config.d/* and
/etc/ssh/ssh_config.d/*, making it possible for all customization and
configuration to be done via 'drop-in' files if desired.
Most users will not need to take any action. The only action required
is if specific Gentoo defaults were overridden in the past, as the new
ebuilds will install them to new files in the new listed directories.
Such admins will need to edit the new files in the new directories or
make overrides in their own files in the new directories using a smaller
number in the filename.
For example, if the system administrator has commented out 'AcceptEnv COLORTERM'
in /etc/ssh/sshd_config, they will need to do the same in the new
/etc/ssh/sshd_config.d/90gentoo.conf file. |
The actual files installed are called 9999999gentoo.conf / 9999999gentoo-security.conf / 9999999gentoo-pam.conf, though. |
|
| Back to top |
|
 |
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20583
|
| Posted: Sat May 13, 2023 7:07 pm Post subject: Re: SSH config-changes |
|
|
| Quote: | Gentoo's OpenSSH package will start using the /etc/ssh/sshd_config.d
and /etc/ssh/ssh_config.d directories for both Gentoo default settings
and use by the administrator. |
Is this an error? The two directories mentioned in the announcement are the same, although the text can read as suggesting the paths should be different.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
figueroa
Advocate
Joined: 14 Aug 2005
Posts: 3007
Location: Edge of marsh USA
|
| Posted: Sat May 13, 2023 7:33 pm Post subject: |
|
|
I'm pretty sure what the news item is suggesting is for users create their own /etc/ssh/sshd_config.d/90gentoo.conf, in other words a file with a LOWER number than the existing default files.
_________________
Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi |
|
| Back to top |
|
|
grknight
Retired Dev
Joined: 20 Feb 2015
Posts: 2000
|
| Posted: Sat May 13, 2023 7:41 pm Post subject: Re: SSH config-changes |
|
|
| pjp wrote: | | Quote: | Gentoo's OpenSSH package will start using the /etc/ssh/sshd_config.d
and /etc/ssh/ssh_config.d directories for both Gentoo default settings
and use by the administrator. |
Is this an error? The two directories mentioned in the announcement are the same, although the text can read as suggesting the paths should be different. |
sshd_config.d and ssh_config.d are not the same. sshd for daemon, ssh for client |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20583
|
| Posted: Sat May 13, 2023 8:37 pm Post subject: Re: SSH config-changes |
|
|
| grknight wrote: | | pjp wrote: | | Quote: | Gentoo's OpenSSH package will start using the /etc/ssh/sshd_config.d
and /etc/ssh/ssh_config.d directories for both Gentoo default settings
and use by the administrator. |
Is this an error? The two directories mentioned in the announcement are the same, although the text can read as suggesting the paths should be different. |
sshd_config.d and ssh_config.d are not the same. sshd for daemon, ssh for client |
Thank you for clarifying. I've always disliked the similarity of those names and didn't think of the difference between client and server. I read it multiple times and never noticed it before asking. *sigh*
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
AJM
Apprentice
Joined: 25 Sep 2002
Posts: 195
Location: Aberdeen, Scotland
|
| Posted: Sat May 13, 2023 10:53 pm Post subject: |
|
|
| Personally I hate this ridiculous proliferation of directories and files when one simple comprehensive file is all that's required. Yet more clutter, mess and obscurity. |
|
| Back to top |
|
|
sublogic
Guru
Joined: 21 Mar 2022
Posts: 303
Location: Pennsylvania, USA
|
| Posted: Sun May 14, 2023 1:03 am Post subject: |
|
|
| AJM wrote: | | Personally I hate this ridiculous proliferation of directories and files when one simple comprehensive file is all that's required. Yet more clutter, mess and obscurity. |
But having subdirectories allow independent packages to install config fragments without trying to splice them in one unified file. For example, /lib/udev/rules.d is populated by many packages. (Although here all the files are owned by openssh).
I'm not a big fan either, but I see the rationale. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20583
|
| Posted: Sun May 14, 2023 5:42 am Post subject: |
|
|
| AJM wrote: | | Personally I hate this ridiculous proliferation of directories and files when one simple comprehensive file is all that's required. Yet more clutter, mess and obscurity. |
For me it depends on the comprehensive file and the implementation of the directory solution. For example, I don't think the current /etc/pam.d solution is good. But I don't think a comprehensive file would be an improvement. The problem is PAM, not the use of a directory.
I don't love the current way ssh/sshd is configured, but I don't know if blowing it out into a bunch of smaller files would be better or worse. If, by your comment, that's what is happening here.
I guess my preference would be using the right tool for the job, not a one-size-fits-all approach.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20583
|
|
| Back to top |
|
|
figueroa
Advocate
Joined: 14 Aug 2005
Posts: 3007
Location: Edge of marsh USA
|
| Posted: Mon May 15, 2023 1:55 am Post subject: |
|
|
I regularly have dispatch-conf try and trick me into allowing my important customizations of /etc/ssh/ssh_config and sshd_config to be removed incident to updates to OpenSSH and am only able to keep them through laborious editing of those files. I'm hoping the adoption of /etc/ssh/ssh_config.d and sshd_config.d directories will protect the customizations that I've moved into /etc/ssh/ssh_config.d/50localssh.conf and /etc/ssh/sshd_config.d/50localsshd.conf.
I took the leap on my main desktop computer, restarted sshd, tested, and made adjustments through some trial and error till everything is working as hoped for. So far, I'm happy with this change.
_________________
Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi |
|
| Back to top |
|
|
freke
Veteran
Joined: 23 Jan 2003
Posts: 1050
Location: Somewhere in Denmark
|
| Posted: Tue May 16, 2023 7:50 pm Post subject: |
|
|
Doesn't this approach allow ebuilds to *sneak* in unwanted changes to my sshd-config?
ie. they set some parameter in 10-foo.conf that I don't explicitely change/unset in a later/higher priority conf?
So I have to check after every emerge that some ebuilds ahve not added files to my sshd-config/dir to ie make sshd unsecure/unusable?
(as in - basically I want my current sshd.config to be reflected in the 999999 sshd.config to be sure) |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3490
|
| Posted: Tue May 16, 2023 8:10 pm Post subject: |
|
|
Are there going to be any negative consequences to just reverting this change locally and not sourcing the drop-in configs from respective directories?
I'm quite happy with the way my ssh works and I'd rather not be messed with right now... And since my config has been manually modified, it should be saved by config-protect, right?
I mean, I already have /etc in git, but I still don't want it to come back to bite me down the line. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 23063
|
| Posted: Tue May 16, 2023 9:19 pm Post subject: |
|
|
| Yes, any time a program accepts all fragments in a directory, other ebuilds can add changes. If that concerns you, then you have a few options. You could use INSTALL_MASK to prohibit installing files in that directory, with an exception for the file(s) you expect ebuilds to provide (such as the main configuration written by net-misc/openssh). You could customize the top level files to use a non-wildcard include of specific personally approved files, such that extra files dropped in the directory are not included and therefore not active. Both of these approaches carry a small risk that it will suppress a desirable change brought in by a secondary ebuild. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20583
|
| Posted: Tue May 16, 2023 10:07 pm Post subject: |
|
|
On the subject of security impact, /etc/ssh/sshd_config has typically not allowed group or other permissions. Is that no longer a concern for /etc/sshd_config.d/ and its contents | Code: | $ ls -ld /etc/ssh/sshd_config{,.d/9*.conf}
-rw------- 1 root root 3156 May 16 13:43 /etc/ssh/sshd_config
-rw-r--r-- 1 root root 316 May 16 13:43 /etc/ssh/sshd_config.d/9999999gentoo.conf
-rw-r--r-- 1 root root 133 May 16 13:43 /etc/ssh/sshd_config.d/9999999gentoo-pam.conf |
| szatox wrote: | | since my config has been manually modified, it should be saved by config-protect, right? |
That is true. ._cfg* files were created on my systems. The new files have an include with wildcard directive to bring in everything in the new *config.d directories. I don't know if there are plans to someday abandon the original files.
I almost ignored the new configuration, but decided to allow it and migrate. Having done so, I think I like the editing convenience it affords. I'm not sure if that's really a good thing or not, as I hadn't considered that files could be dropped into those directories without informed consent. So I'll probably have to change the wildcard settings and only allow my changes and the gentoo changes (existing files "today"). Which means I still have to manage updates to the primary config files. I guess one line is better than enough that has made upgrades a pain.
EDIT:
For the client, this works for the Include line: | Code: | | Include "/etc/ssh/ssh_config.d/9999999gentoo.conf" "/etc/ssh/ssh_config.d/9999999gentoo-security.conf" |
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
figueroa
Advocate
Joined: 14 Aug 2005
Posts: 3007
Location: Edge of marsh USA
|
| Posted: Wed May 17, 2023 1:48 am Post subject: |
|
|
Would there be a downside to changing the permission of the default files in /etc/ssh/sshd_config.d/ to just owner rw with no group and all permissions? The one that I added, 50localsshd.conf (my configuration changes) is owner rw only.
_________________
Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 2113
|
| Posted: Wed May 17, 2023 2:41 am Post subject: |
|
|
| pjp wrote: | On the subject of security impact, /etc/ssh/sshd_config has typically not allowed group or other permissions. Is that no longer a concern for /etc/sshd_config.d/ and its contents | Code: | $ ls -ld /etc/ssh/sshd_config{,.d/9*.conf}
-rw------- 1 root root 3156 May 16 13:43 /etc/ssh/sshd_config
-rw-r--r-- 1 root root 316 May 16 13:43 /etc/ssh/sshd_config.d/9999999gentoo.conf
-rw-r--r-- 1 root root 133 May 16 13:43 /etc/ssh/sshd_config.d/9999999gentoo-pam.conf |
| szatox wrote: | | since my config has been manually modified, it should be saved by config-protect, right? |
That is true. ._cfg* files were created on my systems. The new files have an include with wildcard directive to bring in everything in the new *config.d directories. I don't know if there are plans to someday abandon the original files.
I almost ignored the new configuration, but decided to allow it and migrate. Having done so, I think I like the editing convenience it affords. I'm not sure if that's really a good thing or not, as I hadn't considered that files could be dropped into those directories without informed consent. So I'll probably have to change the wildcard settings and only allow my changes and the gentoo changes (existing files "today"). Which means I still have to manage updates to the primary config files. I guess one line is better than enough that has made upgrades a pain.
EDIT:
For the client, this works for the Include line: | Code: | | Include "/etc/ssh/ssh_config.d/9999999gentoo.conf" "/etc/ssh/ssh_config.d/9999999gentoo-security.conf" |
|
Please file a bug for this with regard to the default permissions.
As for packages dropping stuff in: there is no intention or plan to allow packages to do that and I wouldn't support it. The idea is for users (or sysadmins of larger deployments) to be able to configure their sshd easier, not for other packages to interfere. I'm likely to add a check in pkg_pre/postinst to indicate any new files added by the openssh ebuild as well so people aren't caught out. |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3490
|
| Posted: Wed May 17, 2023 9:55 am Post subject: |
|
|
| Quote: | | As for packages dropping stuff in: there is no intention or plan to allow packages to do that and I wouldn't support it. The idea is for users (or sysadmins of larger deployments) to be able to configure their sshd easier, not for other packages to interfere. I'm likely to add a check in pkg_pre/postinst to indicate any new files added by the openssh ebuild as well so people aren't caught out. |
It's pretty obvious choice for stuff like cron, logrotate, apache (which doesn't really use it the way its configured by gentoo) or haproxy (which by default doesn't use it anywhere I know even though it is supported), as those configs often define a bunch of unrelated items which could be enabled/disabled at any time independently of each other.
SSH doesn't seem to fit that bill though, and automatic configuration has long been solved with templates.
At this point I'm actually curious what is the story behind this idea in case of ssh. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20583
|
| Posted: Wed May 17, 2023 5:48 pm Post subject: |
|
|
| sam_ wrote: | | Please file a bug for this with regard to the default permissions. |
Done. https://bugs.gentoo.org/906639
| sam_ wrote: | | As for packages dropping stuff in: there is no intention or plan to allow packages to do that and I wouldn't support it. The idea is for users (or sysadmins of larger deployments) to be able to configure their sshd easier, not for other packages to interfere. I'm likely to add a check in pkg_pre/postinst to indicate any new files added by the openssh ebuild as well so people aren't caught out. |
Thanks for the clarification and reassurance. My practical concern is more about something accidentally breaking. Config protection averts most issues, but an errant new file could be a big pain.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20583
|
| Posted: Wed May 17, 2023 5:58 pm Post subject: |
|
|
| szatox wrote: | SSH doesn't seem to fit that bill though, and automatic configuration has long been solved with templates.
At this point I'm actually curious what is the story behind this idea in case of ssh. |
Could you elaborate on "solved with templates"?
I'm curious about the origin of the change, but I can guess... it makes updates easier.
The original file doesn't need to change, and modifications override the default. If nothing changes in the default file, I don't have to worry about "what changed" because my changes cause me to have to pay close attention to the proposed ._cfg file. Now, if there is a new file for either the client or server, I _know_ something has changed and need to pay attention to it. The 9999999gentoo* files have very little in them. If they change, it will be easy to see what is changing. One of my files is 42 lines long with spacing and comments.
To make sure I didn't break anything, I methodically went through my client configs to extract my modifications. I did break something, but it was a copy/paste error. After that, I went on to my other system and repeated the process. I fortunately didn't break anything there. All in all, the time spent was not trivial (I could have been doing something "useful"). With the new directories, I expect that process to either go away or be much less involved.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3490
|
| Posted: Wed May 17, 2023 8:24 pm Post subject: |
|
|
Sure.
Starting with this point:
| Quote: | | The idea is for users (or sysadmins of larger deployments) to be able to configure their sshd easier, not for other packages to interfere |
These are 2 completely opposite approaches, none of which really has the problem to solve. A "user" won't mind modifying a single, almost empty file directly.
A larger deployment is a more enterprise-y scenario, which calls for actual tools for centralized management. E.g. I've been working with ansible; puppet, salt and others exist too, and although syntax varies, I'm pretty sure they will all provide similar features, and this is where the fun begins:
In ansible, you define your inventory, which is a list of machines you manage and their desired state.
The state is defined as a hierarchy of variables.
A variable can be assigned to a single machine directly, or to a group and inherited by all members.
One of the modules called "template", provided by ansible, allows you to copy a text file from manager's resource to the managed machine and replace variables with values assigned to the host on the fly.
So, lets say you define 2 hosts:
dns with ip 1.2.3.4
webhost with ip 5.6.7.8
you can define a templates for /etc/hostname
| Code: | | {{ inventory_hostname }} |
and /etc/resolv.conf
| Code: | | nameserver {{ host_vars['dns']['ansible_host'] }} |
and when you push it to webhost, they will be replaced with
and
respectively.
No matter how many times you apply this template and what the previous state of those files was, the result will always be the same, making it _predictable_ which is actually quite important when managing a large number of machines and trying to be as hands-off as possible to avoid getting overwhelmed yourself.
Tracking drop-in files is much more tricky, since you can only be confident about drop-in files you created. Everything else may or may not be needed, and if it's not needed it might be breaking your config. Since you don't have a single Source of Truth anymore, you can't confidently say whether the config is correct or not. You don't know whether or not you should remove drop-in files you haven't created. It is a complication you should not introduce unless you have a really good reason to put up with whatever crap will be coming your way when you least expect it.
Now, you _can_ manage drop-ins with ansible too. But there is no reason to do so; it's more complicated than putting an IF in that jinja template. Need variables from more hosts than one? Ad them all to a group and loop over this group in the template.
Hell, you can even conditionally include another template and it will still create a single file as its output. A single file you can _easily_ track, because it will always be named the same. Doing only 1, atomic operation means there is nothing to orchestrate. No race conditions, no unwanted interactions... That's a bunch of pitfalls you don't have to worry about. |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 2113
|
| Posted: Wed May 17, 2023 9:38 pm Post subject: |
|
|
The user group is so they don't have to keep mangling dispatch-conf because they changed their sshd port.
The large deployment group was a request from a large consumer of Gentoo (although I only found out they're using this internally after I'd already drafted it for the GitHub thing below). And templating doesn't mean you want everything in a massive file. People are free to use the old method if they want.
All of this, however, was motivated by the mess we had when trying to update the ebuild to allow blacklisting GitHub's revoked RSA key. |
|
| Back to top |
|
|
AJM
Apprentice
Joined: 25 Sep 2002
Posts: 195
Location: Aberdeen, Scotland
|
| Posted: Wed May 17, 2023 10:16 pm Post subject: |
|
|
| pjp wrote: | I'm curious about the origin of the change, but I can guess... it makes updates easier.
The original file doesn't need to change, and modifications override the default. If nothing changes in the default file, I don't have to worry about "what changed" because my changes cause me to have to pay close attention to the proposed ._cfg file. Now, if there is a new file for either the client or server, I _know_ something has changed and need to pay attention to it. |
Isn't that what etc-update solves though? I've virtually always found it to be a great tool for (1) seeing what maintainers would like to add / change in config files and (2) ensuring that my custom alterations are carried over. Certainly easier than say using vimdiff with Debian configs which I also use frequently. All these extra 2 or 3 line config files are just more debris to wade through for me... |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 23063
|
| Posted: Wed May 17, 2023 10:54 pm Post subject: |
|
|
| As sam_ said immediately above, the new scheme avoids the need to interact with etc-update / dispatch-conf, because the tools can recognize that the live file is exactly what the previous version of the package installed, and so replacing it with the new version's file cannot lose any user changes. In contrast, with a single file that contains both Gentoo-maintainer directives and local-administrator directives, you will likely need to review the file and selectively keep pieces from each side. |
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3468
Location: Canada
|
| Posted: Thu May 18, 2023 7:51 pm Post subject: |
|
|
| sublogic wrote: | | AJM wrote: | | Personally I hate this ridiculous proliferation of directories and files when one simple comprehensive file is all that's required. Yet more clutter, mess and obscurity. |
But having subdirectories allow independent packages to install config fragments without trying to splice them in one unified file. For example, /lib/udev/rules.d is populated by many packages. (Although here all the files are owned by openssh).
I'm not a big fan either, but I see the rationale. |
I'd be worried if independent packages were changing config of my SSH SERVER |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 2113
|
| Posted: Thu May 18, 2023 8:05 pm Post subject: |
|
|
| I already said that won't happen. |
|
| Back to top |
|
|
|
Networking & Security
