Bug #8342 “ssh: PasswordAuthentication no should result in UsePA...” : Bugs : openssh package : Ubuntu

Revision history for this message

In Debian Bug tracker #250369, Darren Tucker (dtucker) wrote on 2004-06-30: Debian bugs: sshd - PAM and password auth: fixed upstream

#1

Hi.
Please excuse the multi-update, these bugs are somewhat related.

The upstream bug [1] for Debian bugs #242119, #238699, #247521, #250369
is now fixed in upstream's CVS.

The patch attached to the bug re-adds PasswordAuthentication via PAM.
Note that this uses a "blind" conversation that will fail if you have
anything beyond simple password authentication; however this is the best
that can be done within SSH's password authentication method. If you
need more comprehensive PAM support, set PasswordAuthentication=no and
use ChallengeResponse/keyboard-interactive.

[1] http://bugzilla.mindrot.org/show_bug.cgi?id=874
(If you're going to backport the patch, there's a couple of other
related patches in CVS that are not attached to the bug).

--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Revision history for this message

In Debian Bug tracker #250369, Marc Haber (mh+debian-bugs) wrote on 2004-07-02:

#2

On Thu, Jul 01, 2004 at 09:29:20AM +1000, Darren Tucker wrote:
> Please excuse the multi-update, these bugs are somewhat related.
>
> The upstream bug [1] for Debian bugs #242119, #238699, #247521,
> #250369 is now fixed in upstream's CVS.

Actually, I think that #250369 is an issue with Debian packaging,
adding UsePAM unconditionally on update which is not intended on
systems that have passwordauthentication=no.

Greetings
Marc

Revision history for this message

In Debian Bug tracker #250369, Darren Tucker (dtucker) wrote on 2004-07-02:

#3

Marc Haber wrote:
> Actually, I think that #250369 is an issue with Debian packaging,
> adding UsePAM unconditionally on update which is not intended on
> systems that have passwordauthentication=no.

I see. I don't think you need to disable PAM entirely (the account and
session modules might still be useful).

What you probably want instead is "ChallengeResponseAuthentication no"
in addition to to "PasswordAuthentication no". This will prevent users
logging on using their passwords via CR/keyboard-interactive, which
appears to be what's happening in your case.

--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Revision history for this message

In Debian Bug tracker #250369, Jamin W. Collins (jcollins) wrote on 2004-09-22: Bug #250369 - silent SSH config changes

#4

severity 250369 serious
thanks

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.

Due to the potential impact of this change (effective reversal of admin
configuration, a voilation of Policy 10.7.3) I'm upgrading the severity
of this bug report to an RC level of "serious".

--
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

Revision history for this message

In Debian Bug tracker #250369, Jamin W. Collins (jcollins) wrote on 2004-09-22: increasing bug severity

#5

severity 250369 serious
thanks

--
Jamin W. Collins

This is the typical unix way of doing things: you string together lots
of very specific tools to accomplish larger tasks. -- Vineet Kumar

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-09-22:

#6

Automatically imported from Debian bug report #250369 http://bugs.debian.org/250369

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-09-22:

#7

Message-ID: <email address hidden>
Date: Sat, 22 May 2004 15:59:53 +0200
From: Marc Haber <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: ssh: PasswordAuthentication no should result in UsePAM No on update

Package: ssh
Version: 1:3.8.1p1-3
Severity: normal

Hi,

my woody systems routinely run with PasswordAuthenticatio No, so that
only ssh keys can be used to log in.

When updating one box to sid for testing purposes, /etc/ssh/ssd_config
was augmented with "UsePam yes", allowing users to log in using their
password. This went unnoticed, unwarned and might introduce a security
risk.

Please consider setting "UsePam no" on systems that have "Password
Authentication No" set on update.

Greetings
Marc

-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.26-zgserver
Locale: LANG=C, LC_CTYPE=C

Versions of packages ssh depends on:
ii adduser 3.53 Add and remove users and groups
ii debconf 1.4.25 Debian configuration management sy
ii dpkg 1.10.21 Package maintenance system for Deb
ii libc6 2.3.2.ds1-12 GNU C Library: Shared libraries an
ii libpam-modules 0.76-21 Pluggable Authentication Modules f
ii libpam-runtime 0.76-21 Runtime support for the PAM librar
ii libpam0g 0.76-21 Pluggable Authentication Modules l
ii libssl0.9.7 0.9.7d-2 SSL shared libraries
ii libwrap0 7.6.dbs-3 Wietse Venema's TCP wrappers libra
ii zlib1g 1:1.2.1.1-3 compression library - runtime

-- debconf information excluded

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-09-22:

#8

Message-ID: <email address hidden>
Date: Thu, 01 Jul 2004 09:29:20 +1000
From: Darren Tucker <email address hidden>
To: <email address hidden>, Bastian Blank <email address hidden>,
<email address hidden>, Giacomo Mulas <email address hidden>,
<email address hidden>, Daniel Whelan <email address hidden>,
<email address hidden>, Marc Haber <email address hidden>
Subject: Debian bugs: sshd - PAM and password auth: fixed upstream

Hi.
Please excuse the multi-update, these bugs are somewhat related.

The upstream bug [1] for Debian bugs #242119, #238699, #247521, #250369
is now fixed in upstream's CVS.

The patch attached to the bug re-adds PasswordAuthentication via PAM.
Note that this uses a "blind" conversation that will fail if you have
anything beyond simple password authentication; however this is the best
that can be done within SSH's password authentication method. If you
need more comprehensive PAM support, set PasswordAuthentication=no and
use ChallengeResponse/keyboard-interactive.

[1] http://bugzilla.mindrot.org/show_bug.cgi?id=874
(If you're going to backport the patch, there's a couple of other
related patches in CVS that are not attached to the bug).

--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-09-22:

#9

Message-ID: <email address hidden>
Date: Fri, 2 Jul 2004 13:25:48 +0200
From: Marc Haber <email address hidden>
To: Darren Tucker <email address hidden>
Cc: <email address hidden>
Subject: Re: Debian bugs: sshd - PAM and password auth: fixed upstream

On Thu, Jul 01, 2004 at 09:29:20AM +1000, Darren Tucker wrote:
> Please excuse the multi-update, these bugs are somewhat related.
>
> The upstream bug [1] for Debian bugs #242119, #238699, #247521,
> #250369 is now fixed in upstream's CVS.

Actually, I think that #250369 is an issue with Debian packaging,
adding UsePAM unconditionally on update which is not intended on
systems that have passwordauthentication=no.

Greetings
Marc

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-09-22:

#10

Message-ID: <email address hidden>
Date: Fri, 02 Jul 2004 21:58:14 +1000
From: Darren Tucker <email address hidden>
To: Marc Haber <email address hidden>
CC: <email address hidden>
Subject: Re: Debian bugs: sshd - PAM and password auth: fixed upstream

Marc Haber wrote:
> Actually, I think that #250369 is an issue with Debian packaging,
> adding UsePAM unconditionally on update which is not intended on
> systems that have passwordauthentication=no.

I see. I don't think you need to disable PAM entirely (the account and
session modules might still be useful).

What you probably want instead is "ChallengeResponseAuthentication no"
in addition to to "PasswordAuthentication no". This will prevent users
logging on using their passwords via CR/keyboard-interactive, which
appears to be what's happening in your case.

--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-09-22:

#11

Message-ID: <20040922004245.GE22822@cerberus>
Date: Tue, 21 Sep 2004 18:42:46 -0600
From: "Jamin W. Collins" <email address hidden>
To: <email address hidden>
Cc: Matthew Vernon <email address hidden>
Subject: Bug #250369 - silent SSH config changes

severity 250369 serious
thanks

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.

Due to the potential impact of this change (effective reversal of admin
configuration, a voilation of Policy 10.7.3) I'm upgrading the severity
of this bug report to an RC level of "serious".

--
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

Message-ID: <20040922004245.GE22822@cerberus>
Date: Tue, 21 Sep 2004 18:42:46 -0600
From: "Jamin W. Collins" <jcollins@asgardsrealm.net>
To: 250369@bugs.debian.org
Cc: Matthew Vernon <matthew@debian.org>
Subject: Bug #250369 - silent SSH config changes

severity 250369 serious
thanks

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.

Due to the potential impact of this change (effective reversal of admin
configuration, a voilation of Policy 10.7.3) I'm upgrading the severity
of this bug report to an RC level of "serious".

-- 
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

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-09-22:

#12

Message-ID: <20040922042232.GF22822@cerberus>
Date: Tue, 21 Sep 2004 22:22:32 -0600
From: "Jamin W. Collins" <email address hidden>
To: <email address hidden>
Subject: increasing bug severity

severity 250369 serious
thanks

--
Jamin W. Collins

This is the typical unix way of doing things: you string together lots
of very specific tools to accomplish larger tasks. -- Vineet Kumar

Revision history for this message

In Debian Bug tracker #250369, Colin Watson (cjwatson) wrote on 2004-10-05: Re: Bug#250369: Bug #250369 - silent SSH config changes

#13

Download full text (3.2 KiB)

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...

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]

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-10-05:

#14

Download full text (3.6 KiB)

Message-ID: <email address hidden>
Date: Tue, 5 Oct 2004 16:08:52 +0100
From: Colin Watson <email address hidden>
To: "Jamin W. Collins" <email address hidden>, <email address hidden>
Cc: Matthew Vernon <email address hidden>, Marc Haber <email address hidden>,
Darren Tucker <email address hidden>
Subject: Re: 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
ChallengeResponseAuthenti...

Message-ID: <20041005150852.GJ19332@riva.ucam.org>
Date: Tue, 5 Oct 2004 16:08:52 +0100
From: Colin Watson <cjwatson@debian.org>
To: "Jamin W. Collins" <jcollins@asgardsrealm.net>, 250369@bugs.debian.org
Cc: Matthew Vernon <matthew@debian.org>, Marc Haber <mh+debian-bugs@zugschlus.de>,
	Darren Tucker <dtucker@zip.com.au>
Subject: Re: 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]

Revision history for this message

In Debian Bug tracker #250369, Colin Watson (cjwatson) wrote on 2004-10-06: Bug#250369: fixed in openssh 1:3.8.1p1-8.sarge.1

#15

Download full text (3.4 KiB)

Source: openssh
Source-Version: 1:3.8.1p1-8.sarge.1

We believe that the bug you reported is fixed in the latest version of
openssh, which is due to be installed in the Debian FTP archive:

openssh-client-udeb_3.8.1p1-8.sarge.1_powerpc.udeb
  to pool/main/o/openssh/openssh-client-udeb_3.8.1p1-8.sarge.1_powerpc.udeb
openssh-server-udeb_3.8.1p1-8.sarge.1_powerpc.udeb
  to pool/main/o/openssh/openssh-server-udeb_3.8.1p1-8.sarge.1_powerpc.udeb
openssh_3.8.1p1-8.sarge.1.diff.gz
  to pool/main/o/openssh/openssh_3.8.1p1-8.sarge.1.diff.gz
openssh_3.8.1p1-8.sarge.1.dsc
  to pool/main/o/openssh/openssh_3.8.1p1-8.sarge.1.dsc
ssh-askpass-gnome_3.8.1p1-8.sarge.1_powerpc.deb
  to pool/main/o/openssh/ssh-askpass-gnome_3.8.1p1-8.sarge.1_powerpc.deb
ssh_3.8.1p1-8.sarge.1_powerpc.deb
  to pool/main/o/openssh/ssh_3.8.1p1-8.sarge.1_powerpc.deb

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Colin Watson <email address hidden> (supplier of updated openssh package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Wed, 6 Oct 2004 14:21:55 +0100
Source: openssh
Binary: ssh-askpass-gnome openssh-client-udeb ssh openssh-server-udeb
Architecture: source powerpc
Version: 1:3.8.1p1-8.sarge.1
Distribution: unstable
Urgency: high
Maintainer: Matthew Vernon <email address hidden>
Changed-By: Colin Watson <email address hidden>
Description:
openssh-client-udeb - Secure shell client for the Debian installer (udeb)
openssh-server-udeb - Secure shell server for the Debian installer (udeb)
ssh - Secure rlogin/rsh/rcp replacement (OpenSSH)
ssh-askpass-gnome - under X, asks user for a passphrase for ssh-add
Closes: 250369
Changes:
openssh (1:3.8.1p1-8.sarge.1) unstable; urgency=high
.
   * If PasswordAuthentication is disabled, then offer to disable
     ChallengeResponseAuthentication too. The current PAM code will attempt
     password-style authentication if ChallengeResponseAuthentication is
     enabled (closes: #250369).
   * This will ask a question of anyone who installed fresh with 1:3.8p1-2 or
     later and then upgraded. Sorry about that ... for this reason, the
     default answer is to leave ChallengeResponseAuthentication enabled.
Files:
d63e92da131d6df7049e9505010c9cc1 906 net standard openssh_3.8.1p1-8.sarge.1.dsc
626617d98ba24152288e8c051a2a7857 148915 net standard openssh_3.8.1p1-8.sarge.1.diff.gz
321b4b50d4ba08aa63142bd7dd6127fd 734088 net standard ssh_3.8.1p1-8.sarge.1_powerpc.deb
6fa176b76ae58fa6559506df86a6b2d4 52304 gnome optional ssh-askpass-gnome_3.8.1p1-8.sarge.1_powerpc.deb
ed919e75de9e9c84bf3b3d83c68b3a44 151086 debian-installer optional openssh-client-udeb_3.8.1p1-8.sarge.1_powerpc.udeb
f6037c18a80469eaf70571133f8995b2 160060 debian-installer optional openssh-s...

Source: openssh
Source-Version: 1:3.8.1p1-8.sarge.1

We believe that the bug you reported is fixed in the latest version of
openssh, which is due to be installed in the Debian FTP archive:

openssh-client-udeb_3.8.1p1-8.sarge.1_powerpc.udeb
  to pool/main/o/openssh/openssh-client-udeb_3.8.1p1-8.sarge.1_powerpc.udeb
openssh-server-udeb_3.8.1p1-8.sarge.1_powerpc.udeb
  to pool/main/o/openssh/openssh-server-udeb_3.8.1p1-8.sarge.1_powerpc.udeb
openssh_3.8.1p1-8.sarge.1.diff.gz
  to pool/main/o/openssh/openssh_3.8.1p1-8.sarge.1.diff.gz
openssh_3.8.1p1-8.sarge.1.dsc
  to pool/main/o/openssh/openssh_3.8.1p1-8.sarge.1.dsc
ssh-askpass-gnome_3.8.1p1-8.sarge.1_powerpc.deb
  to pool/main/o/openssh/ssh-askpass-gnome_3.8.1p1-8.sarge.1_powerpc.deb
ssh_3.8.1p1-8.sarge.1_powerpc.deb
  to pool/main/o/openssh/ssh_3.8.1p1-8.sarge.1_powerpc.deb

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 250369@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Colin Watson <cjwatson@debian.org> (supplier of updated openssh package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Wed,  6 Oct 2004 14:21:55 +0100
Source: openssh
Binary: ssh-askpass-gnome openssh-client-udeb ssh openssh-server-udeb
Architecture: source powerpc
Version: 1:3.8.1p1-8.sarge.1
Distribution: unstable
Urgency: high
Maintainer: Matthew Vernon <matthew@debian.org>
Changed-By: Colin Watson <cjwatson@debian.org>
Description: 
 openssh-client-udeb - Secure shell client for the Debian installer (udeb)
 openssh-server-udeb - Secure shell server for the Debian installer (udeb)
 ssh        - Secure rlogin/rsh/rcp replacement (OpenSSH)
 ssh-askpass-gnome - under X, asks user for a passphrase for ssh-add
Closes: 250369
Changes: 
 openssh (1:3.8.1p1-8.sarge.1) unstable; urgency=high
 .
   * If PasswordAuthentication is disabled, then offer to disable
     ChallengeResponseAuthentication too. The current PAM code will attempt
     password-style authentication if ChallengeResponseAuthentication is
     enabled (closes: #250369).
   * This will ask a question of anyone who installed fresh with 1:3.8p1-2 or
     later and then upgraded. Sorry about that ... for this reason, the
     default answer is to leave ChallengeResponseAuthentication enabled.
Files: 
 d63e92da131d6df7049e9505010c9cc1 906 net standard openssh_3.8.1p1-8.sarge.1.dsc
 626617d98ba24152288e8c051a2a7857 148915 net standard openssh_3.8.1p1-8.sarge.1.diff.gz
 321b4b50d4ba08aa63142bd7dd6127fd 734088 net standard ssh_3.8.1p1-8.sarge.1_powerpc.deb
 6fa176b76ae58fa6559506df86a6b2d4 52304 gnome optional ssh-askpass-gnome_3.8.1p1-8.sarge.1_powerpc.deb
 ed919e75de9e9c84bf3b3d83c68b3a44 151086 debian-installer optional openssh-client-udeb_3.8.1p1-8.sarge.1_powerpc.udeb
 f6037c18a80469eaf70571133f8995b2 160060 debian-installer optional openssh-server-udeb_3.8.1p1-8.sarge.1_powerpc.udeb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Colin Watson <cjwatson@debian.org> -- Debian developer

iD8DBQFBY/vp9t0zAhD6TNERAtdhAJ9bu1VapW3fNFQB5zXxFCJUBNpIYgCfcX0z
HwytYYrAEqeCEyKEeExgnVk=
=qon2
-----END PGP SIGNATURE-----

Revision history for this message

In Debian Bug tracker #250369, Colin Watson (cjwatson) wrote on 2004-10-06: Fixed in upload of openssh 1:3.8.1p1-11 to experimental

#16

tag 250369 + fixed-in-experimental

quit

This message was generated automatically in response to an
upload to the experimental distribution. The .changes file follows.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Wed, 6 Oct 2004 14:28:20 +0100
Source: openssh
Binary: ssh-askpass-gnome openssh-client-udeb ssh openssh-server openssh-client openssh-server-udeb
Architecture: source powerpc all
Version: 1:3.8.1p1-11
Distribution: experimental
Urgency: high
Maintainer: Matthew Vernon <email address hidden>
Changed-By: Colin Watson <email address hidden>
Description:
openssh-client - Secure shell client, an rlogin/rsh/rcp replacement
openssh-client-udeb - Secure shell client for the Debian installer (udeb)
openssh-server - Secure shell server, an rshd replacement
openssh-server-udeb - Secure shell server for the Debian installer (udeb)
ssh - Secure shell client and server (transitional package)
ssh-askpass-gnome - under X, asks user for a passphrase for ssh-add
Closes: 250369
Changes:
openssh (1:3.8.1p1-11) experimental; urgency=high
.
   * Move sshd_config(5) to openssh-server, where it belongs.
   * If PasswordAuthentication is disabled, then offer to disable
     ChallengeResponseAuthentication too. The current PAM code will attempt
     password-style authentication if ChallengeResponseAuthentication is
     enabled (closes: #250369).
   * This will ask a question of anyone who installed fresh with 1:3.8p1-2 or
     later and then upgraded. Sorry about that ... for this reason, the
     default answer is to leave ChallengeResponseAuthentication enabled.
Files:
e266a814dc81b58b960bd7779d1ae8b4 924 net standard openssh_3.8.1p1-11.dsc
6f8a867493efb1ce008cddfa9c8747d9 142843 net standard openssh_3.8.1p1-11.diff.gz
bfc83f1ba5af125bdafa5c8a016fe2e4 520098 net standard openssh-client_3.8.1p1-11_powerpc.deb
ec4ccbd6cf80f692dcfe731f3448c840 257150 net optional openssh-server_3.8.1p1-11_powerpc.deb
0e5a32c506bcb38398db871164a6ee15 29400 net optional ssh_3.8.1p1-11_all.deb
131180115189e34b7545b91ebdb049d1 53706 gnome optional ssh-askpass-gnome_3.8.1p1-11_powerpc.deb
4f0746107f60e07dee7ac62663d0e3a5 151068 debian-installer optional openssh-client-udeb_3.8.1p1-11_powerpc.udeb
f38a64442352980099c9224dc009c1c2 160048 debian-installer optional openssh-server-udeb_3.8.1p1-11_powerpc.udeb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Colin Watson <email address hidden> -- Debian developer

iD8DBQFBZAgA9t0zAhD6TNERAnmCAKCD220KQta2OjhKTPDMEWViME88IACffe5/
42JKYi0gzkwd4liq9+ZhoU4=
=YGwf
-----END PGP SIGNATURE-----

tag 250369 + fixed-in-experimental

quit

This message was generated automatically in response to an
upload to the experimental distribution.  The .changes file follows.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Wed,  6 Oct 2004 14:28:20 +0100
Source: openssh
Binary: ssh-askpass-gnome openssh-client-udeb ssh openssh-server openssh-client openssh-server-udeb
Architecture: source powerpc all
Version: 1:3.8.1p1-11
Distribution: experimental
Urgency: high
Maintainer: Matthew Vernon <matthew@debian.org>
Changed-By: Colin Watson <cjwatson@debian.org>
Description: 
 openssh-client - Secure shell client, an rlogin/rsh/rcp replacement
 openssh-client-udeb - Secure shell client for the Debian installer (udeb)
 openssh-server - Secure shell server, an rshd replacement
 openssh-server-udeb - Secure shell server for the Debian installer (udeb)
 ssh        - Secure shell client and server (transitional package)
 ssh-askpass-gnome - under X, asks user for a passphrase for ssh-add
Closes: 250369
Changes: 
 openssh (1:3.8.1p1-11) experimental; urgency=high
 .
   * Move sshd_config(5) to openssh-server, where it belongs.
   * If PasswordAuthentication is disabled, then offer to disable
     ChallengeResponseAuthentication too. The current PAM code will attempt
     password-style authentication if ChallengeResponseAuthentication is
     enabled (closes: #250369).
   * This will ask a question of anyone who installed fresh with 1:3.8p1-2 or
     later and then upgraded. Sorry about that ... for this reason, the
     default answer is to leave ChallengeResponseAuthentication enabled.
Files: 
 e266a814dc81b58b960bd7779d1ae8b4 924 net standard openssh_3.8.1p1-11.dsc
 6f8a867493efb1ce008cddfa9c8747d9 142843 net standard openssh_3.8.1p1-11.diff.gz
 bfc83f1ba5af125bdafa5c8a016fe2e4 520098 net standard openssh-client_3.8.1p1-11_powerpc.deb
 ec4ccbd6cf80f692dcfe731f3448c840 257150 net optional openssh-server_3.8.1p1-11_powerpc.deb
 0e5a32c506bcb38398db871164a6ee15 29400 net optional ssh_3.8.1p1-11_all.deb
 131180115189e34b7545b91ebdb049d1 53706 gnome optional ssh-askpass-gnome_3.8.1p1-11_powerpc.deb
 4f0746107f60e07dee7ac62663d0e3a5 151068 debian-installer optional openssh-client-udeb_3.8.1p1-11_powerpc.udeb
 f38a64442352980099c9224dc009c1c2 160048 debian-installer optional openssh-server-udeb_3.8.1p1-11_powerpc.udeb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Colin Watson <cjwatson@debian.org> -- Debian developer

iD8DBQFBZAgA9t0zAhD6TNERAnmCAKCD220KQta2OjhKTPDMEWViME88IACffe5/
42JKYi0gzkwd4liq9+ZhoU4=
=YGwf
-----END PGP SIGNATURE-----

Revision history for this message

Colin Watson (cjwatson) wrote on 2004-10-06:

#17

backport patch from Debian Edit (37.8 KiB, text/plain)

Created an attachment (id=361)
backport patch from Debian

This patch upgrades us to 1:3.8.1p1-11, because the only other change in that
version is trivial and it makes version handling simpler if I do it this way.

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-10-06:

#18

Download full text (3.6 KiB)

Message-Id: <email address hidden>
Date: Wed, 06 Oct 2004 10:47:10 -0400
From: Colin Watson <email address hidden>
To: <email address hidden>
Subject: Bug#250369: fixed in openssh 1:3.8.1p1-8.sarge.1

Source: openssh
Source-Version: 1:3.8.1p1-8.sarge.1

We believe that the bug you reported is fixed in the latest version of
openssh, which is due to be installed in the Debian FTP archive:

openssh-client-udeb_3.8.1p1-8.sarge.1_powerpc.udeb
  to pool/main/o/openssh/openssh-client-udeb_3.8.1p1-8.sarge.1_powerpc.udeb
openssh-server-udeb_3.8.1p1-8.sarge.1_powerpc.udeb
  to pool/main/o/openssh/openssh-server-udeb_3.8.1p1-8.sarge.1_powerpc.udeb
openssh_3.8.1p1-8.sarge.1.diff.gz
  to pool/main/o/openssh/openssh_3.8.1p1-8.sarge.1.diff.gz
openssh_3.8.1p1-8.sarge.1.dsc
  to pool/main/o/openssh/openssh_3.8.1p1-8.sarge.1.dsc
ssh-askpass-gnome_3.8.1p1-8.sarge.1_powerpc.deb
  to pool/main/o/openssh/ssh-askpass-gnome_3.8.1p1-8.sarge.1_powerpc.deb
ssh_3.8.1p1-8.sarge.1_powerpc.deb
  to pool/main/o/openssh/ssh_3.8.1p1-8.sarge.1_powerpc.deb

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Colin Watson <email address hidden> (supplier of updated openssh package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Wed, 6 Oct 2004 14:21:55 +0100
Source: openssh
Binary: ssh-askpass-gnome openssh-client-udeb ssh openssh-server-udeb
Architecture: source powerpc
Version: 1:3.8.1p1-8.sarge.1
Distribution: unstable
Urgency: high
Maintainer: Matthew Vernon <email address hidden>
Changed-By: Colin Watson <email address hidden>
Description:
openssh-client-udeb - Secure shell client for the Debian installer (udeb)
openssh-server-udeb - Secure shell server for the Debian installer (udeb)
ssh - Secure rlogin/rsh/rcp replacement (OpenSSH)
ssh-askpass-gnome - under X, asks user for a passphrase for ssh-add
Closes: 250369
Changes:
openssh (1:3.8.1p1-8.sarge.1) unstable; urgency=high
.
   * If PasswordAuthentication is disabled, then offer to disable
     ChallengeResponseAuthentication too. The current PAM code will attempt
     password-style authentication if ChallengeResponseAuthentication is
     enabled (closes: #250369).
   * This will ask a question of anyone who installed fresh with 1:3.8p1-2 or
     later and then upgraded. Sorry about that ... for this reason, the
     default answer is to leave ChallengeResponseAuthentication enabled.
Files:
d63e92da131d6df7049e9505010c9cc1 906 net standard openssh_3.8.1p1-8.sarge.1.dsc
626617d98ba24152288e8c051a2a7857 148915 net standard openssh_3.8.1p1-8.sarge.1.diff.gz
321b4b50d4ba08aa63142bd7dd6127fd 734088 net standard ssh_3.8.1p1-8.sarge.1_powerpc.deb
6fa176b76ae58fa6559506df86a6b2d4 52304 gnome optional ssh-askpass-gnome_3....

Message-Id: <E1CFD4Q-0001Wa-00@newraff.debian.org>
Date: Wed, 06 Oct 2004 10:47:10 -0400
From: Colin Watson <cjwatson@debian.org>
To: 250369-close@bugs.debian.org
Subject: Bug#250369: fixed in openssh 1:3.8.1p1-8.sarge.1

Source: openssh
Source-Version: 1:3.8.1p1-8.sarge.1

We believe that the bug you reported is fixed in the latest version of
openssh, which is due to be installed in the Debian FTP archive:

openssh-client-udeb_3.8.1p1-8.sarge.1_powerpc.udeb
  to pool/main/o/openssh/openssh-client-udeb_3.8.1p1-8.sarge.1_powerpc.udeb
openssh-server-udeb_3.8.1p1-8.sarge.1_powerpc.udeb
  to pool/main/o/openssh/openssh-server-udeb_3.8.1p1-8.sarge.1_powerpc.udeb
openssh_3.8.1p1-8.sarge.1.diff.gz
  to pool/main/o/openssh/openssh_3.8.1p1-8.sarge.1.diff.gz
openssh_3.8.1p1-8.sarge.1.dsc
  to pool/main/o/openssh/openssh_3.8.1p1-8.sarge.1.dsc
ssh-askpass-gnome_3.8.1p1-8.sarge.1_powerpc.deb
  to pool/main/o/openssh/ssh-askpass-gnome_3.8.1p1-8.sarge.1_powerpc.deb
ssh_3.8.1p1-8.sarge.1_powerpc.deb
  to pool/main/o/openssh/ssh_3.8.1p1-8.sarge.1_powerpc.deb

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 250369@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Colin Watson <cjwatson@debian.org> (supplier of updated openssh package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Wed,  6 Oct 2004 14:21:55 +0100
Source: openssh
Binary: ssh-askpass-gnome openssh-client-udeb ssh openssh-server-udeb
Architecture: source powerpc
Version: 1:3.8.1p1-8.sarge.1
Distribution: unstable
Urgency: high
Maintainer: Matthew Vernon <matthew@debian.org>
Changed-By: Colin Watson <cjwatson@debian.org>
Description: 
 openssh-client-udeb - Secure shell client for the Debian installer (udeb)
 openssh-server-udeb - Secure shell server for the Debian installer (udeb)
 ssh        - Secure rlogin/rsh/rcp replacement (OpenSSH)
 ssh-askpass-gnome - under X, asks user for a passphrase for ssh-add
Closes: 250369
Changes: 
 openssh (1:3.8.1p1-8.sarge.1) unstable; urgency=high
 .
   * If PasswordAuthentication is disabled, then offer to disable
     ChallengeResponseAuthentication too. The current PAM code will attempt
     password-style authentication if ChallengeResponseAuthentication is
     enabled (closes: #250369).
   * This will ask a question of anyone who installed fresh with 1:3.8p1-2 or
     later and then upgraded. Sorry about that ... for this reason, the
     default answer is to leave ChallengeResponseAuthentication enabled.
Files: 
 d63e92da131d6df7049e9505010c9cc1 906 net standard openssh_3.8.1p1-8.sarge.1.dsc
 626617d98ba24152288e8c051a2a7857 148915 net standard openssh_3.8.1p1-8.sarge.1.diff.gz
 321b4b50d4ba08aa63142bd7dd6127fd 734088 net standard ssh_3.8.1p1-8.sarge.1_powerpc.deb
 6fa176b76ae58fa6559506df86a6b2d4 52304 gnome optional ssh-askpass-gnome_3.8.1p1-8.sarge.1_powerpc.deb
 ed919e75de9e9c84bf3b3d83c68b3a44 151086 debian-installer optional openssh-client-udeb_3.8.1p1-8.sarge.1_powerpc.udeb
 f6037c18a80469eaf70571133f8995b2 160060 debian-installer optional openssh-server-udeb_3.8.1p1-8.sarge.1_powerpc.udeb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Colin Watson <cjwatson@debian.org> -- Debian developer

iD8DBQFBY/vp9t0zAhD6TNERAtdhAJ9bu1VapW3fNFQB5zXxFCJUBNpIYgCfcX0z
HwytYYrAEqeCEyKEeExgnVk=
=qon2
-----END PGP SIGNATURE-----

Revision history for this message

Colin Watson (cjwatson) wrote on 2004-10-06:

#19

Reviewed by LaMont and Daniel Stone:

openssh (1:3.8.1p1-11ubuntu1) warty; urgency=low

* Merge from Debian (closes: Ubuntu #1586).

-- Colin Watson <email address hidden> Wed, 6 Oct 2004 16:08:04 +0100

openssh (1:3.8.1p1-11) experimental; urgency=high

  * Move sshd_config(5) to openssh-server, where it belongs.
  * If PasswordAuthentication is disabled, then offer to disable
    ChallengeResponseAuthentication too. The current PAM code will attempt
    password-style authentication if ChallengeResponseAuthentication is
    enabled (closes: #250369).
  * This will ask a question of anyone who installed fresh with 1:3.8p1-2 or
    later and then upgraded. Sorry about that ... for this reason, the
    default answer is to leave ChallengeResponseAuthentication enabled.

-- Colin Watson <email address hidden> Wed, 6 Oct 2004 14:28:20 +0100

Revision history for this message

In Debian Bug tracker #250369, Colin Watson (cjwatson) wrote on 2004-10-06: needs to be fixed in sarge too

#20

reopen 250369
tags 250369 = sarge
thanks

--
Colin Watson [<email address hidden>]

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-10-06:

#21

Message-Id: <email address hidden>
Date: Wed, 06 Oct 2004 11:17:05 -0400
From: Colin Watson <email address hidden>
To: <email address hidden>
Cc: Colin Watson <email address hidden>, Matthew Vernon <email address hidden>
Subject: Fixed in upload of openssh 1:3.8.1p1-11 to experimental

tag 250369 + fixed-in-experimental

quit

This message was generated automatically in response to an
upload to the experimental distribution. The .changes file follows.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Wed, 6 Oct 2004 14:28:20 +0100
Source: openssh
Binary: ssh-askpass-gnome openssh-client-udeb ssh openssh-server openssh-client openssh-server-udeb
Architecture: source powerpc all
Version: 1:3.8.1p1-11
Distribution: experimental
Urgency: high
Maintainer: Matthew Vernon <email address hidden>
Changed-By: Colin Watson <email address hidden>
Description:
openssh-client - Secure shell client, an rlogin/rsh/rcp replacement
openssh-client-udeb - Secure shell client for the Debian installer (udeb)
openssh-server - Secure shell server, an rshd replacement
openssh-server-udeb - Secure shell server for the Debian installer (udeb)
ssh - Secure shell client and server (transitional package)
ssh-askpass-gnome - under X, asks user for a passphrase for ssh-add
Closes: 250369
Changes:
openssh (1:3.8.1p1-11) experimental; urgency=high
.
   * Move sshd_config(5) to openssh-server, where it belongs.
   * If PasswordAuthentication is disabled, then offer to disable
     ChallengeResponseAuthentication too. The current PAM code will attempt
     password-style authentication if ChallengeResponseAuthentication is
     enabled (closes: #250369).
   * This will ask a question of anyone who installed fresh with 1:3.8p1-2 or
     later and then upgraded. Sorry about that ... for this reason, the
     default answer is to leave ChallengeResponseAuthentication enabled.
Files:
e266a814dc81b58b960bd7779d1ae8b4 924 net standard openssh_3.8.1p1-11.dsc
6f8a867493efb1ce008cddfa9c8747d9 142843 net standard openssh_3.8.1p1-11.diff.gz
bfc83f1ba5af125bdafa5c8a016fe2e4 520098 net standard openssh-client_3.8.1p1-11_powerpc.deb
ec4ccbd6cf80f692dcfe731f3448c840 257150 net optional openssh-server_3.8.1p1-11_powerpc.deb
0e5a32c506bcb38398db871164a6ee15 29400 net optional ssh_3.8.1p1-11_all.deb
131180115189e34b7545b91ebdb049d1 53706 gnome optional ssh-askpass-gnome_3.8.1p1-11_powerpc.deb
4f0746107f60e07dee7ac62663d0e3a5 151068 debian-installer optional openssh-client-udeb_3.8.1p1-11_powerpc.udeb
f38a64442352980099c9224dc009c1c2 160048 debian-installer optional openssh-server-udeb_3.8.1p1-11_powerpc.udeb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Colin Watson <email address hidden> -- Debian developer

iD8DBQFBZAgA9t0zAhD6TNERAnmCAKCD220KQta2OjhKTPDMEWViME88IACffe5/
42JKYi0gzkwd4liq9+ZhoU4=
=YGwf
-----END PGP SIGNATURE-----

Message-Id: <E1CFDXN-0002Il-00@newraff.debian.org>
Date: Wed, 06 Oct 2004 11:17:05 -0400
From: Colin Watson <cjwatson@debian.org>
To: control@bugs.debian.org
Cc: Colin Watson <cjwatson@debian.org>, Matthew Vernon <matthew@debian.org>
Subject: Fixed in upload of openssh 1:3.8.1p1-11 to experimental

tag 250369 + fixed-in-experimental

quit

This message was generated automatically in response to an
upload to the experimental distribution.  The .changes file follows.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Wed,  6 Oct 2004 14:28:20 +0100
Source: openssh
Binary: ssh-askpass-gnome openssh-client-udeb ssh openssh-server openssh-client openssh-server-udeb
Architecture: source powerpc all
Version: 1:3.8.1p1-11
Distribution: experimental
Urgency: high
Maintainer: Matthew Vernon <matthew@debian.org>
Changed-By: Colin Watson <cjwatson@debian.org>
Description: 
 openssh-client - Secure shell client, an rlogin/rsh/rcp replacement
 openssh-client-udeb - Secure shell client for the Debian installer (udeb)
 openssh-server - Secure shell server, an rshd replacement
 openssh-server-udeb - Secure shell server for the Debian installer (udeb)
 ssh        - Secure shell client and server (transitional package)
 ssh-askpass-gnome - under X, asks user for a passphrase for ssh-add
Closes: 250369
Changes: 
 openssh (1:3.8.1p1-11) experimental; urgency=high
 .
   * Move sshd_config(5) to openssh-server, where it belongs.
   * If PasswordAuthentication is disabled, then offer to disable
     ChallengeResponseAuthentication too. The current PAM code will attempt
     password-style authentication if ChallengeResponseAuthentication is
     enabled (closes: #250369).
   * This will ask a question of anyone who installed fresh with 1:3.8p1-2 or
     later and then upgraded. Sorry about that ... for this reason, the
     default answer is to leave ChallengeResponseAuthentication enabled.
Files: 
 e266a814dc81b58b960bd7779d1ae8b4 924 net standard openssh_3.8.1p1-11.dsc
 6f8a867493efb1ce008cddfa9c8747d9 142843 net standard openssh_3.8.1p1-11.diff.gz
 bfc83f1ba5af125bdafa5c8a016fe2e4 520098 net standard openssh-client_3.8.1p1-11_powerpc.deb
 ec4ccbd6cf80f692dcfe731f3448c840 257150 net optional openssh-server_3.8.1p1-11_powerpc.deb
 0e5a32c506bcb38398db871164a6ee15 29400 net optional ssh_3.8.1p1-11_all.deb
 131180115189e34b7545b91ebdb049d1 53706 gnome optional ssh-askpass-gnome_3.8.1p1-11_powerpc.deb
 4f0746107f60e07dee7ac62663d0e3a5 151068 debian-installer optional openssh-client-udeb_3.8.1p1-11_powerpc.udeb
 f38a64442352980099c9224dc009c1c2 160048 debian-installer optional openssh-server-udeb_3.8.1p1-11_powerpc.udeb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Colin Watson <cjwatson@debian.org> -- Debian developer

iD8DBQFBZAgA9t0zAhD6TNERAnmCAKCD220KQta2OjhKTPDMEWViME88IACffe5/
42JKYi0gzkwd4liq9+ZhoU4=
=YGwf
-----END PGP SIGNATURE-----

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-10-06:

#22

Message-ID: <email address hidden>
Date: Wed, 6 Oct 2004 17:41:40 +0100
From: Colin Watson <email address hidden>
To: <email address hidden>
Subject: needs to be fixed in sarge too

reopen 250369
tags 250369 = sarge
thanks

--
Colin Watson [<email address hidden>]

Revision history for this message

In Debian Bug tracker #250369, Jamin W. Collins (jcollins) wrote on 2004-10-07: Re: Bug#250369: Bug #250369 - silent SSH config changes

#23

Download full text (5.1 KiB)

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
> con...

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

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-10-07:

#24

Download full text (5.5 KiB)

Message-ID: <20041007185742.GK9210@cerberus>
Date: Thu, 7 Oct 2004 12:57:43 -0600
From: "Jamin W. Collins" <email address hidden>
To: Colin Watson <email address hidden>
Cc: <email address hidden>, Matthew Vernon <email address hidden>,
Marc Haber <email address hidden>, Darren Tucker <email address hidden>
Subject: Re: 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 dis...

Message-ID: <20041007185742.GK9210@cerberus>
Date: Thu, 7 Oct 2004 12:57:43 -0600
From: "Jamin W. Collins" <jcollins@asgardsrealm.net>
To: Colin Watson <cjwatson@debian.org>
Cc: 250369@bugs.debian.org, Matthew Vernon <matthew@debian.org>,
	Marc Haber <mh+debian-bugs@zugschlus.de>, Darren Tucker <dtucker@zip.com.au>
Subject: Re: Bug#250369: Bug #250369 - silent SSH config changes