OK, I can see similar behaviour on Linux with 6.8p1 with PAM enabled. This
is the debug output from a slightly modified openssh client:
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug1: input_userauth_info_req: name '' instructions '' lang ''
debug2: input_userauth_info_req: num_prompts 1
Password:
debug2: input_userauth_info_req
debug1: input_userauth_info_req: name '' instructions '' lang ''
debug2: input_userauth_info_req: num_prompts 0
debug1: Enabling compression at level 6.
On Tue, Apr 7, 2015 at 12:29 AM, Peter Gutmann <pgut001@xxxxxxxxxxxxxxxxx>
wrote:
>
> to which I reply with a SSH_MSG_USERAUTH_INFO_RESPONSE. The server then
> sends
> a second SSH_MSG_USERAUTH_INFO_REQUEST consisting of 16 bytes of zeros:
>
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>
> for which, even if you ignore the fact that it fails a data-validity check,
>
Assuming that's the whole packet, I think that's a
zero-prompt USERAUTH_INFO_REQUEST packet containing empty name,
instructions and language strings. What do you mean by "fails a
data-validity check"?
If it was just the prompt part of the packet, what's in the name and
instruction fields?
I'm not sure how you're supposed to respond, since it's asked for zero
> responses to its authentication request.
>
Zero prompts is specifically allowed by RFC4256 section 3.2:
" The num-prompts field may be `0', in which case there will be no
prompt/echo fields in the message, but the client SHOULD still
display the name and instruction fields (as described below)."
In my case, those strings are empty, so sshd probably shouldn't generate
them (I'll dig into why they get generated) but it seems like a valid (if
pointless) protocol message to me.
--
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.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
