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)