On Mon, 2021-06-14 at 20:20 +0200, Michael Ströder wrote:

On 6/14/21 8:03 PM, Dominique Leuenberger / DimStar wrote:

...

OpenSSH: move of the distro default config to /usr/etc. Admin config is supposed to be in /etc. Make sure to check the .rpmsave files after the update.

You removed the *existing* admin config, unconditionally enforcing openSUSE defaults, and expect admins to *manually* clean up / restore later.

This is definitely wrong update behaviour!

This leads to security policy violations!

It locks out admins to clean up via SSH later! Hint: Not every VM has a console, e.g. in Azure.

Yes, I know that you will probably ignore me and everybody else critisizing your approach.

Serious? Getting too few atention lately? Let me re-write here the exact phrase I replied to a message of yours last Friday It can also be found in the archives https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/2... The text was: """ In pam we had pre/posttrans scriptlets covering the user from falling into this trap. This should also be done in openssh, like the example on https://en.opensuse.org/openSUSE:Packaging_UsrEtc#Moving_of_configuration_f… Care to file a big or even an SR? Cheers, Dominique """ Have you done so? Or did you ignore me because 'the answer was not in line with your believe of being ignored' ? Cheers, Dominique

Hi Michael, On Mon, 2021-06-14 at 21:47 +0200, Michael Ströder wrote:

On 6/14/21 9:16 PM, Dominique Leuenberger / > Care to file a big or even an SR?

...

Cheers, Dominique """

Have you done so? Or did you ignore me because 'the answer was not in line with your believe of being ignored' ?

You insist that people should *manually* move back .rpmsave files just like also documented here:

https://en.opensuse.org/openSUSE:Packaging_UsrEtc#Moving_of_configuration_fi...

"RPM will save the modified configuration files as *.rpmsave files at the end of the update process. This files need to be renamed back to the original file name."

But IMO this should not be done if the config file was changed by the admin and differs from the old packaged default config.

So what should *I* write into a ticket?

A ticket needs a definition of done people agreed to. Otherwise it's just garbage and nobody will work on it.

Ciao, Michael.

ok, I think now I see where we differ - it's our understanding of the target audience of that paragraph in the wiki. You interpret it as addressing the admin - I interpret it as addressing the packager. Especially the example given in it, how pam solves it, clearly in the spec file by the packager, gives, to me, the impression that the packager is the one having to care for it, especially in packages like this (for pam this was also done, as ignoring the local modifications could render a system rapidly unusable) (my view is supported by the fact that the paragraph 'Movigng of configuration files' lives under the heading called "What does this mean for the developer/packager?") So, technically, I'd strive for: * from a packager PoV, pre/posttrans scriptlet should be added as is done in pam * from an admin PoV, the admin should strive to eliminate /etc/ssh/sshd_config and put his local variations in (muliple, topic based) files in /etc/ssh/sshd_config.d The first point ensures users upgrading from an openSSH having the config in /etc to one having it in /usr/etc will not end up with an unexpeced config The 2nd ensures the admin has a well controlled config, that inherits new security features as they come by. I hope that helps clarifying things up a bit. Cheers, Dominique

Martin Wilck wrote:

On Di, 2021-06-15 at 08:40 +0200, Dominique Leuenberger / DimStar wrote:

...

So, technically, I'd strive for:

* from a packager PoV, pre/posttrans scriptlet should be added as is done in pam * from an admin PoV, the admin should strive to eliminate /etc/ssh/sshd_config and put his local variations in (muliple, topic based) files in /etc/ssh/sshd_config.d

We've got a general problem here IMO, not just an openssh issue.  Moving a shipped configuration file marked %config or %config(noreplace) from /etc to some location under /usr is dangerous.

Yes. Ideally rpm would just deal with that in a smart way without packagers having to deal with nasty and error prone scriptlets. There are some tickets filed upstream related to that but so far no developer picked it up. https://github.com/rpm-software-management/rpm/issues/1522 https://github.com/rpm-software-management/rpm/issues/1296 https://github.com/rpm-software-management/rpm/issues/1178 cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)

G'day guys, On 15/6/21 4:40 pm, Dominique Leuenberger / DimStar wrote:

Hi Michael,

On Mon, 2021-06-14 at 21:47 +0200, Michael Ströder wrote:

...

On 6/14/21 9:16 PM, Dominique Leuenberger / > Care to file a big or even an SR?

...

Cheers, Dominique """

Have you done so? Or did you ignore me because 'the answer was not in line with your believe of being ignored' ?

You insist that people should *manually* move back .rpmsave files just like also documented here:

https://en.opensuse.org/openSUSE:Packaging_UsrEtc#Moving_of_configuration_fi... <https://protect-au.mimecast.com/s/u2ltC2xMqmcpzZY8u1tPnD?domain=en.opensuse.org>

...

"RPM will save the modified configuration files as *.rpmsave files at the end of the update process. This files need to be renamed back to the original file name."

ok, I think now I see where we differ - it's our understanding of the target audience of that paragraph in the wiki.

You interpret it as addressing the admin - I interpret it as addressing the packager. Especially the example given in it, how pam solves it, clearly in the spec file by the packager, gives, to me, the impression that the packager is the one having to care for it, especially in packages like this (for pam this was also done, as ignoring the local modifications could render a system rapidly unusable)

Although it looks like it is intended for package managers, I would assume it would have to be interpreted as only in 'most circumstances'. It would surely be dependent on the package. It does not deal with the case where it is not just a move from /etc to /usr/etc but also a move from a single file to a directory containing files. In this case, a different pretrans would be better. It also doesn't address the case where the config file has changed enough that the intent of the Admin would no longer be served with the old file. In this case, informing the admin to move config as needed (or use a posttrans script and still informing the Admin to check it) would probably be better than the package manager just moving/renaming it. It also means that sometimes Admins do not know about the shiny new knob they could tweak in their package because it is only in the rpmnew file, so they will not tweak it, and that leads to less life satisfaction (we know that Admins live to tweak things.. ok maybe they should run "find /etc -name \*rpmnew" etc)

So, technically, I'd strive for:

* from a packager PoV, pre/posttrans scriptlet should be added as is done in pam

The example for pam may not apply as well to this particular update of ssh. On my system, it looks like it went form a single file in /etc/ssh to a directory containing files. It seems that in pretty much every case where configurations go from a single /etc/foo_config file to having a default config in /usr/etc/foo_config which includes /etc/foo_config.d/*.config on an upgrade, the easiest way to deal with it is to create /etc/foo_config.d, move the old /etc/foo_config file to "foo_config.d/rpmsave.conf", and then put the new config file in place in /usr which references foo.d. That way, old settings are retained, and the new format is still there (albeit without separate files, but if someone is actively administering that, they will do that themselves). This means that after the upgrade all of the config will be there, usually*. It is the same intent as the policy. It would be nice if RPM did this automagically, but this is fairly simple pretrans stuff. In this case, a pretrans to do the directory creation and file move would probably have made it so nobody even noticed (but then, this is Tumbleweed, the Tumbleweed user base include the sort of people who look at stuff like this). Perhaps this should be the default behaviour of RPM rather than just renaming to rpmsave/rpmnew, but then, default is not the mantra of Tumbleweed user-base. This is another reason I think policies for package maintainers like "This files need to be renamed back to the original file name" can only work in "most cases".

* from an admin PoV, the admin should strive to eliminate /etc/ssh/sshd_config and put his local variations in (muliple, topic based) files in /etc/ssh/sshd_config.d The 2nd ensures the admin has a well controlled config, that inherits new security features as they come by.

I agree that something.conf.d/ is the best way to deal with it, as long as packages can do includes. I still think RPMs should still drop "rpmnew" sections in there when there are new config items (not activated because they have rpmnew instead of conf at the end) so Admins can find the shiny new knobs easier. Maybe all of this will be all fixed when defaults are in /usr. Probably not though. I am waiting for the day when "ls /" just shows "usr", and "ls /usr" just shows what used to be in root, but without usr. Then people will be saying we need a new way to move the config from /usr/etc/something.conf to /usr/etc/default-configs/overrides/tuesday/something_active.d.. ironically, that is still possible in pre/posttrans. * The ssh config files in /usr/etc feel wrong to me. They have the include for /etc/ssh/ssh(d)_config.d about half way though the file, and then AFTER the include, they have other configuration items. This means the default in /usr may override whatever admins really want. What if I want "AuthorizedKeysFile .ssh/authorized_keys" to be "AuthorizedKeysFile .ssh/authorised_keys" to confuse the Americans? I would have to change the /usr/etc/ssh/sshd_config file! -- Ben

On 16.06.2021 05:39, Ben Holmes wrote:

* The ssh config files in /usr/etc feel wrong to me. They have the include for /etc/ssh/ssh(d)_config.d about half way though the file, and

They are included as the very first non-comment statement in these files.

then AFTER the include, they have other configuration items. This means the default in /usr may override whatever admins really want.

man sshd_config For each keyword, the first obtained value will be used.

Am Wed, 16 Jun 2021 08:48:15 +0300 schrieb Andrei Borzenkov <arvidjaar@gmail.com>:

For each keyword, the first obtained value will be used.

... unless it is "Subsystem", in which case the second "sftp" configuration will fail. This might be the reason why one can not simply move the rpmsave file into sshd_config.d. Olaf

On 6/16/21 9:50 AM, Olaf Hering wrote:

Am Wed, 16 Jun 2021 08:48:15 +0300 schrieb Andrei Borzenkov <arvidjaar@gmail.com>:

...

For each keyword, the first obtained value will be used.

... unless it is "Subsystem", in which case the second "sftp" configuration will fail.

This might be the reason why one can not simply move the rpmsave file into sshd_config.d.

I also wonder how conditional blocks defined by Match are handled with /etc/ssh/sshd_config.d/. Ciao, Michael.

On 6/16/21 11:30 AM, Martin Wilck wrote:

On Mi, 2021-06-16 at 10:53 +0200, Michael Ströder wrote:

...

I also wonder how conditional blocks defined by Match are handled with /etc/ssh/sshd_config.d/.

sshd_config(5) says about "Include":

"Multiple pathnames may be specified and each pathname may contain glob(7) wildcards that will be expanded and processed in lexical order"

and

"An Include directive may appear inside a Match block to perform conditional inclusion".

Conditional Include in a Match section is not an issue if done right. But as described in sshd_config(5) a Match section is terminated by EOF or another Match section. AFAICS this means that all Match sections have to be included at the *end* of the config file *after* all global config directives. But /usr/etc/ssh/sshd_config now contains at the *beginning*: Include /etc/ssh/sshd_config.d/*.conf The unconditional globbing is my concern: AFAICS if somebody puts a Match section in /etc/ssh/sshd_config.d/match-section.conf this would mask all other *global* config directives in /usr/etc/ssh/sshd_config and all other config files included after match-section.conf. To me this seems not to be well-designed and it causes more trouble than it will ever solve. Could be solved by two separate Include statements though. BTW this pseudo-config management is the reason why I generate monolithic custom config files for almost all services I'm running. Because everything else is a higher security risk. Normally I don't complain in such a case. I just fix things mostly with ansible plays. But in this particular case SSH lockout means config management does not work anymore. :-(( (Before anybody answers with "use salt". Similar config management lockout can happen with salt if someone breaks your custom salt agent config. Not to speak if you're using salt-ssh.) Ciao, Michael.

On 17.06.2021 07:50, Andrei Borzenkov wrote:

On 16.06.2021 13:05, Michael Ströder wrote:

...

On 6/16/21 11:30 AM, Martin Wilck wrote:

...

On Mi, 2021-06-16 at 10:53 +0200, Michael Ströder wrote:

...

I also wonder how conditional blocks defined by Match are handled with /etc/ssh/sshd_config.d/.

sshd_config(5) says about "Include":

"Multiple pathnames may be specified and each pathname may contain glob(7) wildcards that will be expanded and processed in lexical order"

and

"An Include directive may appear inside a Match block to perform conditional inclusion".

Conditional Include in a Match section is not an issue if done right.

But as described in sshd_config(5) a Match section is terminated by EOF or another Match section. AFAICS this means that all Match sections have to be included at the *end* of the config file *after* all global config directives.

But /usr/etc/ssh/sshd_config now contains at the *beginning*:

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

The unconditional globbing is my concern: AFAICS if somebody puts a Match section in

/etc/ssh/sshd_config.d/match-section.conf

this would mask all other *global* config directives in /usr/etc/ssh/sshd_config and all other config files included after match-section.conf.

I cannot make Match section to work in #include'ed file at all.

And judging by this comment this is intentional /* * don't let Match in includes clobber the * containing file's Match state. */ Which means it is not possible to replace ssh configuration file with include directory at all.

oot@bor-Latitude-E5450:/etc/ssh# grep -Ev '^#|^$' sshd_config Include /etc/ssh/sshd_config.d/*.conf ChallengeResponseAuthentication no UsePAM yes X11Forwarding yes PrintMotd no AcceptEnv LANG LC_* Subsystem sftp /usr/lib/openssh/sftp-server Match Host foo PermitEmptyPasswords yes root@bor-Latitude-E5450:/etc/ssh# sshd -T | grep permitem permitemptypasswords no root@bor-Latitude-E5450:/etc/ssh# sshd -T -C host=foo | grep permitem permitemptypasswords yes root@bor-Latitude-E5450:/etc/ssh#

Now move Match block into included file

root@bor-Latitude-E5450:/etc/ssh# grep -Ev '^#|^$' sshd_config Include /etc/ssh/sshd_config.d/*.conf ChallengeResponseAuthentication no UsePAM yes X11Forwarding yes PrintMotd no AcceptEnv LANG LC_* Subsystem sftp /usr/lib/openssh/sftp-server root@bor-Latitude-E5450:/etc/ssh# cat sshd_config.d/01.conf Match Host foo PermitEmptyPasswords yes root@bor-Latitude-E5450:/etc/ssh# sshd -T | grep permitem permitemptypasswords no root@bor-Latitude-E5450:/etc/ssh# sshd -T -C host=foo | grep permitem permitemptypasswords no root@bor-Latitude-E5450:/etc/ssh#

...

To me this seems not to be well-designed and it causes more trouble than it will ever solve. Could be solved by two separate Include statements though.

BTW this pseudo-config management is the reason why I generate monolithic custom config files for almost all services I'm running. Because everything else is a higher security risk.

Normally I don't complain in such a case. I just fix things mostly with ansible plays. But in this particular case SSH lockout means config management does not work anymore. :-((

(Before anybody answers with "use salt". Similar config management lockout can happen with salt if someone breaks your custom salt agent config. Not to speak if you're using salt-ssh.)

Ciao, Michael.

On 14/06/2021 19:58, Oliver Schwabedissen wrote:

Am 14.06.21 um 20:03 schrieb Dominique Leuenberger / DimStar:

...

AS noted in my last weekly review: OpenSSH: move of the distro default config to /usr/etc. Admin config is supposed to be in /etc. Make sure to check the .rpmsave files after the update. Best to put config snippets in /etc/ssh/sshd_config.d/*.conf

On my system,  /etc/ssh/sshd_config was simply removed and a new one created in /usr/etc/ssh. No .rpmsave file was created,

Anyhow, no problem here as root is not allowed to log in through ssh, only one user can login.

Regards,

Oliver

Exactly the same here. Copying those files from /usr/etc/ssh to /etc/ssh, /etc/ssh/ssh_config.d/ or /etc/sshd_config.d/ makes no difference when sshd.service is restarted. No problem if that's the new normal,  I can live with login as user and using "su -" for a root prompt. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks