I built a PAM module which only responsibility is sending a challenge to the end-user in the form of a (unique) url. No input is required, nor appreciated. openssh however, discards all conversation of type PAM_TEXT_INFO and PAM_ERROR_MSG until the PAM module returns control. All conversation of type PAM_PROMPT_ECHO_[ON|OFF] is honoured, but I don't want the user to need to enter something, not even <enter> before returning the authentication result. I know displaying messages of type PAM_ERROR_MSG is frowned upon and regarded as leaking information, but PAM_TEXT_INFO is there for a reason. Please reconsider displaying them, without the need for user interaction.
Which authentication method are you using? The behaviour that you describe is probably true for password authentication, because the protocol doesn't really allow arbitrary messages while that's happening. You should try disabling password authentication and using keyboard-interactive authentication instead, as it allows informational prompts.
This is what debug tells me at the moment my PAM pluging takes over: debug1: Next authentication method: keyboard-interactive
(In reply to Damien Miller from comment #1) > You should try disabling password authentication and using > keyboard-interactive authentication instead, as it allows > informational prompts. Looking at the code, I think it's the case for keyboard-interactive too: sshpam_query([...] case PAM_ERROR_MSG: case PAM_TEXT_INFO: /* accumulate messages */ len = plen + mlen + 2; [etc] I think it's that way because the same conversation function had to handle both Protocol 2 keyboard-interactive and Protocol 1 TIS challenge-response. The latter is fairly limited, but is now (mercifully) gone.
The code below that comment appears to be filling in the challenge-response prompts, which gets sent immediately via auth2-chall.c:send_userauth_info_request -> kbdintctxt->device->query (auth-pam.c:sshpam_query) AFAIK this already supports multiple rounds of prompting, but maybe the PAM code doesn't? I'm rusty on that...
All I know is that it works for PAM_PROMPT_ECHO_[ON|OFF] in OpenSSH and it doesn't for PAM_TEXT_INFO. Also, in pamtester they work both.
(In reply to Damien Miller from comment #4) > The code below that comment appears to be filling in the > challenge-response prompts, which gets sent immediately via It's dependent on the ordering of the PAM messages with the conversation struct. INFO first will probably work, PROMPT_ECHO.* probably won't. > AFAIK this already supports multiple rounds of prompting, but maybe > the PAM code doesn't? I'm rusty on that... It sort of does but not in the general case. The way it currently works with only one prompt per round was required for SSH1 TIS but not SSH2 keyboard-int.
INFO is the only message I want to send and first doesn't make a difference (in my case it's always first). It's never sent immediately. PROMPT allways gets sent immediately.
Created attachment 3160 [details] assign ERROR_MSG/TEXT_INFO messages to kbd-int information field I think we can just assign these messages to *info - this ends up in the instruction field in SSH_MSG_USERAUTH_INFO_REQUEST and being printed by the client too. This would mean we send SSH_MSG_USERAUTH_INFO_REQUEST messages to the client with no prompts, but this is permitted by the protocol AFAIK and our client at least seems to support it (though I bet there are others that will choke...) We don't really have a choice though - we can't tell a priori what the next message from the PAM subprocess is going to be and it will block for prompt messages.
That diff is insufficient (or maybe wrong). It gets the PAM subprocess desyncronised in sshpam_respond(), since that expects num==1 only.
Hi Damien. Is there any way we could assist with the effort here? MFA logins (e.g., Duo) are becoming more and more ubiquitous. When MFA is in play, it can be pretty important that PAM_TEXT_INFO messages are pushed immediately, instead of being collected until the next PAM_PROMPT_ECHO_[ON|OFF] response. E.g., the PAM_TEXT_INFO message could be this: "Hey, we just auto-pushed an auth request to your mobile device, so if it looks like your login session just hung, maybe go grab your phone and approve the request? Or just sit there staring dumbly at the screen for 90 seconds until the push request times out. Your call." I get why the /* accumulate messages */ logic was the case historically (because SSH protocol version 1 was teh suck), but now that SSHv1 is (deservedly) dead, it would be great to address this for SSHv2 keyboard-interactive auth. If there's a concern about potentially breaking other ssh clients (e.g. comment 8), perhaps the "push PAM_TEXT_INFO messages immediately" behavior could be toggled by an option? E.g., PAMImmmediateNotifications? If you can come up with a tentative patch, we'd be happy to help test it, against multiple different ssh clients we have here (OpenSSH, Putty, et. al.)
Created attachment 3610 [details] Extension to Damien Millers patch
Sorry, forgot to comment my patch, quite new to this bugzilla stuff. Does anyone know why sshpam_respond only wants num=1? I tried doing num=2 from the PAM_TEXT_INFO case, but ended up just getting sshpam_device.query failed back as an error. (also, my patch seems to be the one where i tried num=2, but that seemed to fail, the actual patch i wanted to upload doesn't have num=2, just checks if its 0).