openssh unix dev - Jul 2021 - Unexpected behavior with "-o PreferredAuthentications=password"

I currently have a lot of keys in my .ssh and this is sometimes a
problem when logging into a system where I have to use a password
because the total allowed authentication attempts are exceeded
before it gets to the password. So I had been using
"-o PreferredAuthentications=password" in those cases.  But I just
found that there's a gotcha with this... on a specific host that had
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.  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").

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

Cheers,
- J?rgen

On Tue, 20 Jul 2021, J?rgen Botz wrote:
> 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").
> about the semantics of 'PreferredAuthentications=password'?
Maybe you need PreferredAuthentications=keyboard-interactive instead?
(Though, I only know the ?user at host password:? message.)

Worth a try,
//mirabilos
-- 
Infrastrukturexperte ? tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn ? http://www.tarent.de/
Telephon +49 228 54881-393 ? Fax: +49 228 54881-235
HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941
Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*************************************************

Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter

*************************************************

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.

On Tue, 20 Jul 2021, J?rgen Botz wrote:
> I currently have a lot of keys in my .ssh and this is sometimes a
> problem when logging into a system where I have to use a password
> because the total allowed authentication attempts are exceeded
> before it gets to the password. So I had been using
> "-o PreferredAuthentications=password" in those cases.  But I
just
> found that there's a gotcha with this... on a specific host that had
> 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.  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").
> 
> 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'?
As others have pointed out, setting this option to just password
also disables the other authentication method that is often used
for password (and challenge-response) authentication.

You probably want:

PreferredAuthentications=keyboard-interactive,password

-d