Bug#250369: Bug #250369 - silent SSH config changes
On Tue, Oct 05, 2004 at 04:08:52PM +0100, Colin Watson wrote:
> 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.
Why? You're changing a configuration file that the admin may have
alerted. Most other packages only blindly update the configuration if
the admin has not change the default. In the case of this report, the
admins have most certainly changed the configuration and like the other
packages the admin should be prompted for this change.
> 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.
I disagree. If the "meaning" hadn't changed the behaviour shouldn't
have changed. That the behaviour did change would seem to indicate that
the "meaning" changed in some way.
> 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 problem is that as it was, password authentication _was_ disabled,
no ifs no ands no buts about it. It was impossible under the
configuration that was in place for a user to make an SSH connection via
password authentication. Thus, the SSH server was effectively (rightly
so or not) configured for keyed authentication only. The change
(however well intended) silently enabled password authentication.
> 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.
As they probably should. The admin of the system should be made aware
of all changes to configuration files they've updated.
> 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.
Most likely, that would be acceptable. The end requirement is what
Policy mandates (10.7.3) that "local changes must be preserved during a
package upgrade". This would seem to indicate the behaviour of the
configured package should remain the same before and after the package
upgrade if at all possible. This is most certainly not the case with
the current SSH upgrade.
I have a feeling a number of current woody system administrators would
be shocked to find SSH changed in this way on their system when
upgrading to sarge.
--
Jamin W. Collins
To be nobody but yourself when the whole world is trying it's best night
and day to make you everybody else is to fight the hardest battle any
human being will fight. -- E.E. Cummings
Reply to: