Unexpected behavior with "-o PreferredAuthentications=password"

[Darren Tucker]

On Wed, 21 Jul 2021 at 07:21, Jürgen Botz <jurgen at botz.org> wrote:

> [...]
> "-o PreferredAuthentications=password" [...]
> a pam configuration to use a 2nd factor (google-authenticator) I
> kept getting "Permission denied; please try again." after the
> password prompt and never getting to the prompt for the authenticator
> code.


The short answer is you want to
use  PreferredAuthentications=keyboard-interactive on your client instead,
or set PasswordAuthentication=no on the server.


> From a different client where I didn't need to use the
> PreferredAuthentications option it worked fine.  Eventually I noticed
> two things...
>
> 1) The password prompt was different; when I used
> PreferredAuthentications it looked like "user at host password:", but
> when I didn't use that option it just says "Password:" (note the capital
> "P").
>

Long answer: in the first case the prompt was generated by the ssh client.
In the second case the prompt was generated by the PAM stack and passed to
the ssh client which just displays whatever it's told.

2) Using "-o PubkeyAuthentication=no" instead of
> PreferredAuthentications resolved my problem.
>
> It would seem that depending on those options the interaction between
> sshd and PAM is different.  Is this is a bug, or am I missing something
> about the semantics of 'PreferredAuthentications=password'?
>

"password" authentication passes a single simple password over the
encrypted channel (RFC4252 section 8).  It has no provision to pass your
Google Authenticator code.

"keyboard-interactive" (RFC4256) allows for an arbitrary number of
arbitrary requests and responses during an authentication.  PAM
configurations can require an arbitrary number of challenges and responses,
so there are PAM configurations (such as yours) that cannot be achieved
with simple password authentication but can be with keyboard-interactive.

When UsePAM is enabled and "password" authentication is attempted, sshd
sets up a simple PAM "conversation function" which blindly answers with the
password to anything PAM asks.  This works for trivial PAM configurations
but not more complicated ones such as yours.  For "keyboard-interactive"
authentications a more complicated conversation function is used that
allows the messages from the PAM stack (such as your "Password:" and Google
Authenticator prompts) to be passed through to the client, and any
responses (such as your password and authenticator code) to be passed back.

If your server has a PAM stack that's too complicated to work with
PasswordAuthentication you probably want to disable it on the server side.

-- 
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.