[Bug 2502] New: using AuthenticationMethods to require s/key and pam doesn't work

[bugzilla-daemon at bugzilla.mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=2502

            Bug ID: 2502
           Summary: using AuthenticationMethods to require s/key and pam
                    doesn't work
           Product: Portable OpenSSH
           Version: 7.1p1
          Hardware: amd64
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: kmk at sanitarium.net

If I put in sshd_config:
UsePAM yes
AuthenticationMethods
keyboard-interactive:skey,keyboard-interactive:pam
ChallengeResponseAuthentication yes
(PasswordAuthentication yes or no doesn't matter)

I would expect to be prompted for an s/key challenge then whatever is
supported by pam.  The intention is to make pam require google
authenticator but I have tried this with Gentoo's stock password setup
too.

When I connect I get partial authentication success from s/key but then
the server hangs up on me.  When I put sshd in debug mode I get this:
...
debug1: authentication methods list 0:
keyboard-interactive:skey,keyboard-interactive:pam
debug1: authentication methods list 0:
keyboard-interactive:skey,keyboard-interactive:pam [preauth]
debug1: PAM: initializing for "kmk"
debug1: PAM: setting PAM_RHOST to "172.22.100.17"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: userauth-request for user kmk service ssh-connection method
keyboard-interactive [preauth]
debug1: attempt 1 failures 0 [preauth]
debug1: keyboard-interactive devs  [preauth]
debug1: auth2_challenge: user=kmk devs= [preauth]
debug1: kbdint_alloc: devices 'pam,skey' [preauth]
debug1: auth2_challenge_start: trying authentication method 'skey'
[preauth]
Postponed keyboard-interactive for kmk from 172.22.100.17 port 56339
ssh2 [preauth]
auth2_update_methods_lists: method not in AuthenticationMethods
debug1: do_cleanup
debug1: PAM: cleanup
debug1: Killing privsep child 1596

I see in the source above that error message:
/* This should not happen, but would be bad if it did */
So maybe this is an unhandled use case?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.