Re: sshd UsePAM, PR bin/32313

[elric%imrryr.org@localhost]

On 1258856485 seconds since the Beginning of the UNIX epoch
Taylor R Campbell wrote:
>

>Last summer, I brought up on netbsd-users the topic of PR bin/32313,
>which is that setting `PasswordAuthentication no' in sshd_config does
>not actually disable password authentication, because NetBSD's default
>sshd_config also includes the undocumented `UsePAM yes'.  This means
>that system administrators may believe they have disabled password
>authentication by following what the documentation indicates, without
>having disabled it at all.
>
>I suggested that NetBSD's default sshd_config omit `UsePAM yes'.  This
>is a one-character change to the file (a comment character).  All of
>the replies -- well, all two of them -- supported this change, but
>nothing happened.  Could someone either object or make the change?

It occurs that part of the problem here is the rather unfortunate
naming convention chosen by openssh ``PasswordAuthentication''
which should be more properly described as:

        Legacy UNIX password Authentication unless you have enabled
        ``KerberosAuthentication'' in which case Kerberos passwords
        will also be attempted in addition to Protocol 1 Kerberos
        ticket-based authentication for which there is no other
        mechanism to enable.

PAM Authentication does not necessarily enable legacy UNIX passwords
as you might be using SecurID or S/Key---or even simply using the
PAM stack to get AFS tokens after a successful Kerberos ticket-based
authentication, to enforce system account management, to register
logins with radius servers, etc.

In a perfect world, I would suggest that we rename PasswordAuthentication
to ``LegacyPasswordAuthention'' or some such and leave it in place
solely for people to use in stripped down appliances or the like
for which PAM is considered to be too heavy weight.  But, unfortunately,
renaming it would introduce incompatibilities with people's
expectations of how opensshd would work and hence this is probably
a non-starter.

I don't think that option 2 that you mentioned in your PR makes
sense as it is not possible to determine a priori whether a particular
PAM stack is using S/Key, SecurID or Radius (and if you are using
Radius whether it accepts a simple passwd or 2 factor authentication).
That is, if you see ``UsePAM yes'' and ``PasswordAuthentication
no'', how do you determine if the PAM stack will accept a password
or not?  And even if it does, what expectation should I have when
I set ``PasswordAuthentication no''?  Should I expect that UNIX
passwords should fail to work?  Should I expect that Kerberos
passwords fail to work?  How does ``ChallengeResponseAuthentication
no'' fit into the mix?

And option 3, i.e. changing PAM to parse sshd_config is not a good
idea either, IMO, as the semantics defined by openssh for sshd_config
authentication are confusing at best and an attractive nuissance
at worst.  Sadly, given that openssh is a security product, it has
one of the worst designed and confusing authentication configuration
mechanisms that I've seen which frequently leads to settings which
are silently insecure.  We should not encourage people to use the
semantics defined by sshd_config.

--
    Roland Dowdeswell                      http://Imrryr.ORG/~elric/