Subject: keyboard-interactive auth

From: der Mouse <[email-masked]>
Date: Thu, 8 Sep 2005 14:47:16 -0400 (EDT)

I'm trying to implement keyboard-interactive authentication, and I
think maybe I've got something written, but when I try to use it
against openssh, I see the exchange go

<<< confirmation of ssh-userauth starting
>>> request mouse/ssh-connection/none
<<< failure, can-continue publickey,password,keyboard-interactive
>>> request mouse/ssh-connection/keyboard-interactive
<<< failure, can-continue publickey,password,keyboard-interactive

This makes no sense to me; I'm not even sure how to interpret it,
besides "server too confused to do keyboard-interactive for this user".

Anyone know what's up with it?

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: der Mouse <[email-masked]>
Date: Thu, 8 Sep 2005 15:49:34 -0400 (EDT)

> "Yeah, Openssh does that."  Openssh does not keep track of whether an
> authentication method has failed to be useful on the server side.  It
> [...] expects the client to deal with this.

Okay, I can live with that (I have to be prepared to do *something* in
the face of arbitrarily broken servers, after all, and it's not that
difficult to keep a list of auth methods that appear to be
misbehaving.)

That answers the question of what openssh means in doing this - it's
rejecting keyboard-interactive auth, just in a way that rather confused
me.  But it raises the question of why openssh is rejecting
keyboard-interactive auth at all.  Any thoughts on that?

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: Sam Hartman <[email-masked]>
Date: Thu, 08 Sep 2005 15:45:25 -0400

>>>>> "der" == der Mouse <[email-masked]> writes:

    der> I'm trying to implement keyboard-interactive authentication, and I
    der> think maybe I've got something written, but when I try to use it
    der> against openssh, I see the exchange go

    der> <<< confirmation of ssh-userauth starting
    >>>> request mouse/ssh-connection/none
    der> <<< failure, can-continue publickey,password,keyboard-interactive
    >>>> request mouse/ssh-connection/keyboard-interactive
    der> <<< failure, can-continue publickey,password,keyboard-interactive

    der> This makes no sense to me; I'm not even sure how to interpret it,
    der> besides "server too confused to do keyboard-interactive for this user".

"Yeah, Openssh does that."  Openssh does not keep track of whether an
authentication method has failed to be useful on the server side.  It
continues to offer all the authentication methods even if they don't
really apply to the current user.  It expects the client to deal with
this.

--Sam

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 08 Sep 2005 16:57:21 -0400

> keyboard-interactive auth at all.  Any thoughts on that?

Depending on the mechanisms in use, it is possible that the server isn't 
rejecting the method, but is deciding to deny access to that user without 
requiring further interaction.  It is certainly possible to configure a PAM 
stack that will behave in this way.

It's also possible that your server is misconfigured in such a way that 
keyboard-interactive is broken.  If the server is configured to use PAM to 
support keyboard-interactive, and there is some problem with the PAM 
configurationm, then I would not be surprised to see behavior along these 
lines.

---

From: Damien Miller <[email-masked]>
Date: Fri, 9 Sep 2005 09:37:53 +1000 (EST)

> keyboard-interactive auth at all.  Any thoughts on that?

I think these implementation-specific questions are best asked on a 
OpenSSH list (or by reading the public source code).

-d

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 09 Sep 2005 15:52:16 +1200

>OpenSSH list (or by reading the public source code).

I disagree.  Problems in OpenSSH affect every other SSH implementation, so 
it's important that other SSH implementers be made aware of issues like this
so they can adjust their own implementation.

(OK, the real issue is that OpenSSH should adjust its behaviour, but given
the huge installed base that won't happen in a hurry).

Peter.

---

From: Damien Miller <[email-masked]>
Date: Fri, 9 Sep 2005 14:32:56 +1000 (EST)

> the huge installed base that won't happen in a hurry).

Well, no. AFAIK OpenSSH's behaviour in this regard is compliant with the 
kbd-int draft.

The server cannot know a priori whether a delegated authentication 
mechanism (probably PAM or BSD-auth in the case of OpenSSH) is going to 
return an instant failure when queried. The draft explicitly caters for 
this circumstance, allowing the server to return SSH_MSG_USERAUTH_FAILURE 
immediately.

-d

---

From: der Mouse <[email-masked]>
Date: Fri, 9 Sep 2005 00:53:19 -0400 (EDT)

>> (OK, the real issue is that OpenSSH should adjust its behaviour, but
>> given the huge installed base that won't happen in a hurry).
> Well, no.  AFAIK OpenSSH's behaviour in this regard is compliant with
> the kbd-int draft.

The latter does not necessarily imply the former; it's entirely
possible that certain behaviour should be adjusted even though it's
entirely conformant.

In this case, I think it should.  See below.

> mechanism (probably PAM or BSD-auth in the case of OpenSSH) is going
> to return an instant failure when queried.  The draft explicitly
> caters for this circumstance, allowing the server to return
> SSH_MSG_USERAUTH_FAILURE immediately.

Sure - but when that failure message lists keyboard-interactive as a
productive method to continue authenticating with it is, at the very
least, confusing.

And that's why I think it should be "adjusted" - and the aspect of it
which I think should be changed.

The situation is a bit messy; as a comment in my source (in the
USERAUTH_FAILURE handling) says:

 /* Four cases:
        (1) partial success, current algorithm listed in methods
                current alg running
                -> continue current alg
        (2) partial success, current algorithm not listed in methods
                current alg succeeded, more auth needed
                -> end current alg
                -> pick next alg
                -> start it
        (3) no partial success, current algorithm listed in methods
                not sure what this can mean - maybe, eg, public key
                failed, but another public key might succeed?
                -> retry current alg
        (4) no partial success, current algorithm not listed in methods
                current alg failed, try another
                -> end current alg
                -> pick next alg
                -> start it
 */

The semantics of these cases (the indented text with no arrow after the
numbered lines) are not clearly laid out in the drafts, as far as I can
tell; what I wrote in that comment was guesses.  (My guess about
publickey seems to have matched current practice; about
keyboard-interactive, not.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: Darren Tucker <[email-masked]>
Date: Mon, 19 Sep 2005 13:40:12 +1000

der Mouse wrote:
[...]
> productive method to continue authenticating with it is, at the very

Just because a given kbdint attempt failed immedaiately does not mean 
that the next one will.  The underlying authentication system may 
provide no way for the server to know.

PAM, for example, makes it pretty much impossible to tell.  The admin 
might configure, for example, a time-based access module before the 
password prompt in the auth stack.  Under those conditions, if your 
first attempt was before the permitted time, the second one might not be.

The admin can arrange for a PAM module to perform pretty much any 
arbitrary test, including external factors.  (server load?  currently 
logged on users?  direction of prevailing breeze?)  Those factors could 
have changed between auth attempts, and the server has no way of knowing 
other than letting the user try again.

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