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 [EMAIL PROTECTED]
