Bug 1191802 - sshd_config settings disabled during update
Summary: sshd_config settings disabled during update
Status: IN_PROGRESS
Alias: None
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Basesystem (show other bugs)
Version: Current
Hardware: aarch64 Other
: P5 - None : Critical (vote)
Target Milestone: ---
Assignee: Hans Petter Jansson
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-10-19 06:07 UTC by Adrian Schröter
Modified: 2021-11-24 07:01 UTC (History)
5 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adrian Schröter 2021-10-19 06:07:56 UTC
/etc/ssh/sshd_config file settings got moved away during package update, only the new ones from the package inside of /usr/etc were active.

This basically disabled all security settings and I noticed due to failed login attempts warning message. This would not have been possible with my config.

I consider this therefore as a quite grave security issue, since it weakens my config (allowing password logins in my cases).
Comment 1 Neil Rickert 2021-10-20 00:25:18 UTC
You are late to the party.  This probably duplicates an earlier bug.

In any case, you can put your preferred "sshd_config" in "/etc/ssh" and it will be used (it will override the file in "/usr/etc/ssh".  But the better approach is to just put your own modifications in a config file in "/etc/ssh/sshd_config.d/".  That way you can go with the latest defaults and only change what you need.
Comment 2 Adrian Schröter 2021-10-20 05:56:28 UTC
maybe I am late, but we did not stop publishing the distribution if we have such grave issues, if this is known already.
Comment 3 Hans Petter Jansson 2021-10-22 13:48:10 UTC
I had a discussion about this with Thorsten at the time. It's unfortunate, but we couldn't find a way for RPM to leave the file alone when upgrading. IMO it's wrong behavior for RPM to delete modified configuration files when the location changes. The workaround is to look for .rpmsave after upgrades.

If there's general interest in the issue of preserving configuration files, I guess we could move this bug to RPM. Otherwise I guess it's time to close it. Opinions?
Comment 4 Adrian Schröter 2021-10-22 15:25:40 UTC
you should be able to handle it in %post, however accepting to drop security settings is in no way acceptable for me.

Alternative is to stop and disable sshd service. This is not creating a security hole at least.

IMHO we should take down factory ftp stream from ftp server until this is fixed to avoid more unsecure systems.
Dominique, what is your position here?
Comment 5 Neil Rickert 2021-10-22 17:41:20 UTC
What particularly bothered me with this update, is that I ran "rpmconfigcheck" after the update, but it did not tell me about the change.  That, at least, should be fixed.

I found out the hard way, when I did an "ssh user@localhost" and got unexpected prompts because of the change to ssh_config.
Comment 6 Hans Petter Jansson 2021-10-22 21:05:12 UTC
What's a good way to handle this in %post? I'd be fine with any solution that actually fixes the problem and doesn't introduce further brittleness/other configuration issues down the line.
Comment 7 Thorsten Kukuk 2021-10-23 08:11:58 UTC
(In reply to Hans Petter Jansson from comment #6)
> What's a good way to handle this in %post? I'd be fine with any solution
> that actually fixes the problem and doesn't introduce further
> brittleness/other configuration issues down the line.

The spec file restores /etc/ssh/sshd_config if that was modified after migration from /etc/ssh to /usr/etc/ssh. 

Question is, why this did not work for Adrian.

(In reply to Adrian Schröter from comment #0)
> /etc/ssh/sshd_config file settings got moved away during package update,
> only the new ones from the package inside of /usr/etc were active.

Please look in the log files, if there are any errors or if you have a /etc/ssh/sshd_config.rpmsave file.
Comment 8 Adrian Schröter 2021-10-25 07:46:07 UTC
I had an /etc/ssh/sshd_config.rpmsave file.

My zypper log files (going back till 2021-08-30) do not match "sshd" anywhere.

Some snippeds from /var/log/zypp/history:

# /etc/ssh/sshd_config: setting to root:root 0640 (wrong permissions 0600)

2020-09-02 18:42:21|install|sysstat|12.4.0-1.2|aarch64||repo-oss|17c1c7e8e4148d6a001e0e5407d7a72e0726e523e594ae7a420138f0c7b715a2|
# 2020-09-02 18:42:24 openssh-8.3p1-1.2.aarch64.rpm installed ok
# Additional rpm output:
# warning: /etc/ssh/sshd_config created as /etc/ssh/sshd_config.rpmnew
# Updating /etc/sysconfig/ssh ...

2021-07-06 13:02:44|install|patterns-base-basesystem|20200505-21.1|aarch64||repo-oss|cb533c26e4f372ca182cc9b71aabf8c9944d67b52a4b6
980a73474e518d8826b|
# 2021-07-06 13:02:46 openssh-server-8.4p1-6.1.aarch64.rpm installed ok
# Additional rpm output:
# renamed '/etc/ssh/sshd_config.rpmsave' -> '/etc/ssh/sshd_config.rpmsave.old'
# /usr/bin/systemd-sysusers -
# Updating /etc/sysconfig/ssh ...


no further hits afterwards.

(This is a Pi4 aarch64 installation, in case it matters)
Comment 9 Thorsten Kukuk 2021-10-25 07:55:11 UTC
Hm, there was a sshd_config.rpmsave file but RPM created a sshd_config.rpmnew file? I don't understand this, if RPM creates *.rpmnew files there shouldn't be *.rpmsave files?

But anyways, looks like the check in the spec file should look for *.rpmnew files and not *.rpmsave files.
Comment 10 Thorsten Kukuk 2021-10-25 07:59:49 UTC
Stop: the *.rpmsave file is created if the config file get's removed from the new RPM, the *.rpmnew get's created if the config file stays, but got modified inside RPM.

Looks like aarch64 is far behind x86-64 again and they just need to release the current openssh package to fix the problem.
Comment 11 Thorsten Kukuk 2021-10-25 08:01:21 UTC
Please tell us the next time from the beginning that this is aarch64 and not a main architecture...
Since aarch64 is most of the time far behind x86-64 and ix86, it often contains bugs already fixed elsewhere.
Comment 12 Hans Petter Jansson 2021-11-23 23:16:03 UTC
Is this still a problem on aarch64?
Comment 13 Adrian Schröter 2021-11-24 07:01:16 UTC
can not tell, I won't do the same update again.