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
