Bug#848089: openssh: silently changes configuration

[Christoph Anton Mitterer <calestyo@scientia.net>]

Source: openssh
Severity: normal


Hi.

I've just stumbled (after much searching, since there seems to be no
changelog entry o.O) over commit 18a9bd1867ee6fb9d913515773b322a279759b5d.

Which automagically/silently replaces "without-password" with "prohibit-password"
for some versions.

First, apparently this doesn't generally work, since I have sid systems where this
has happened and some where it didn't, even though all are on the same version of
the package now.


Since I was quite sure that I didn't set prohibit-password and since don't use
the default config file shipped/generated by the package, I was pretty concerned
at first that there might have been some intrusion.
So second, why is that change done silently/automagically at all?
Doesn't policy 10.7.3 "local changes must be preserved during a package upgrade"
imply that this is forbidden?
And shouldn't one at least get some interaction or sshd_config.dpkg-new or similar
hint that you mangled around with the config?

In this case the change is not serious, of course, since the two mean the same, but
it still has an effect, e.g. when the ssh config is checked with rkhunter and that
in turn configured with ALLOW_SSH_ROOT_USER=without-password .


There's another case where you, AFAICT, silently mangle around with the config
that may be user modified:
        if dpkg --compare-versions "$2" lt-nl 1:6.6p1-1 && \
           [ "$(get_config_option PermitRootLogin)" = yes ] &&
           db_get openssh-server/permit-root-login && [ "$RET" = true ]; then
            set_config_option PermitRootLogin prohibit-password
        fi

Obviously this is in a way a good change, as it makes things more secure, but
AFAIU it's also applied on every config, whether the user made modifications
or not... and there doesn't seem to be a corresponding entry in NEWS.Debian.




Generally I'd say you never should make such auto-magical changes since there may
be situations in which you just break things or even make them less secure, and
this may not be directly visible.
E.g. sshd_config may make use of Match blocks and only some of the directives
should be changed while others shouldn't where as you auto-magic cannot know which.

But if you really feel you'd need to do such changes, properly document in
NEWS.Debian, even if it seems the change may be simple and just safe for everyone.



Cheers,
Chris.



-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.8.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)