Bug#250369: Bug #250369 - silent SSH config changes
On Tue, Sep 21, 2004 at 06:42:46PM -0600, Jamin W. Collins wrote:
> severity 250369 serious
> thanks
Sorry for the delay in responding to this bug; work has been busy.
Fortunately, I now have to deal with this bug for work in any event ...
> The following section of ssh's postinst appears to be responsible for
> the rather shocking change to ssh's configuration.
>
> elif dpkg --compare-versions "$oldversion" lt-nl 1:3.8p1-1 && \
> ! grep -iq ^UsePAM /etc/ssh/sshd_config ; then
> # Upgrade from pre-3.7: UsePAM needed to maintain standard
> # Debian configuration.
> echo -n 'Upgrading sshd_config (old version in .dpkg-old) ...'
> cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.dpkg-old
> perl -pe 's/^(PAMAuthenticationViaKbdInt|RhostsAuthentication)\b/#$1/i' \
> /etc/ssh/sshd_config > /etc/ssh/sshd_config.dpkg-new
> echo >> /etc/ssh/sshd_config.dpkg-new
> echo 'UsePAM yes' >> /etc/ssh/sshd_config.dpkg-new
> mv /etc/ssh/sshd_config.dpkg-new /etc/ssh/sshd_config
> echo
> return 0
> else return 0
>
> I had disabled password authentication on all of my systems immediately
> after installation. Today, I noticed and confirmed that password
> authentication was once again working for ssh on most of them.
>
> This forced a reduction in each of the effected system's security and
> completely reversed my configuration as administrator of those machines.
>
> I would expect changes of this nature to prompt the administrator to
> accept them.
Well, as noted in the comment at the top of your quote from the postinst
above, the addition of 'UsePAM yes' was required in order to maintain
the standard configuration (the upstream configuration file changes
between 3.6 and 3.7 were hairy at best). Prompting would be unacceptable
in this case. Debian OpenSSH has used PAM for a long time for
configuration consistency with other parts of the system, and it needs
to continue doing so on upgrade or the support burden will become too
heavy.
To put it another way, the problem is not that the code above changed
your configuration. It didn't - at least not the meaning. PAM was the
default before, and it's still the default; it's just that the actual
text of the configuration file had to change in order to keep it that
way. The problem is that it didn't change your configuration *enough* to
cope with other changes in how authentication is configured.
The effective re-enabling of authentication with passwords was certainly
not intentional, and, as Darren points out, it's not necessary to
disable PAM in order to fix this problem: disabling
ChallengeResponseAuthentication should be sufficient. At this point the
configuration file changes start to look rather frightening to do
entirely automatically.
Would you (Marc and Jamin) be happy with a change to spot
'PasswordAuthentication no' on upgrade and ask whether
ChallengeResponseAuthentication should also be disabled? This appears to
disable authentication with passwords in my tests. I think that's the
best I can do.
Cheers,
--
Colin Watson [cjwatson@debian.org]
Reply to: