Forward-port from HEAD:

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

1 files changed, 16 insertions, 0 deletions

diff --git a/debian/openssh-server.templates.master b/debian/openssh-server.templates.master
index e6d355639..af4d4e9f8 100644
--- a/debian/openssh-server.templates.master
+++ b/debian/openssh-server.templates.master
@@ -77,3 +77,19 @@ _Description: Warning: you must create a new host key
  from the old (non-free) SSH installation.
  .
  You will need to generate a new host key.
+
+Template: ssh/disable_cr_auth
+Type: boolean
+Default: false
+_Description: Disable challenge-response authentication?
+ Password authentication appears to be disabled in your current OpenSSH
+ server configuration. In order to prevent users from logging in using
+ passwords (perhaps using only public key authentication instead) with
+ recent versions of OpenSSH, you must disable challenge-response
+ authentication, or else ensure that your PAM configuration does not allow
+ Unix password file authentication.
+ .
+ If you disable challenge-response authentication, then users will not be
+ able to log in using passwords. If you leave it enabled (the default
+ answer), then the 'PasswordAuthentication no' option will have no useful
+ effect unless you also adjust your PAM configuration in /etc/pam.d/ssh.