Autopush status message not flushed about duo_unix HOT 8 CLOSED

Sigh, I unintentionally duped this in #164, because I thought this was a different problem.

The reason why sshd accumulates PAM_TEXT_INFO messages until the next interaction with the client is because the same conversation code had to handle communication with both protocol version 1 and protocol version 2 clients, and the SSH version 1 protocol challenge-response could only communicate messages to the client as part of a challenge-response pair.

But since OpenSSH no longer supports protocol version 1, it should be possible to find a way to push PAM_TEXT_INFO messages to the client without waiting for the next challenge-response.

Upstream took a crack at it back in 2018, here:

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

…but that effort appears to have fizzled out at the time, because difficult.

I hopped onto the Bugzilla and offered to help push the effort forward any way that I can.

from duo_unix.

What OS and OS version are you using? Also, what version of Duo Unix?

In my testing I see Autopushing login request to phone... before the successful authentication.

from duo_unix.

CentOS 7.2, using duo_unix-1.9.17-0.x86_64 RPM

from duo_unix.

Hmm, interesting.

I was able to reproduce your behavior on CentOS 7, yet on Ubuntu 14.04 I see the expected behavior.

from duo_unix.

I think the issue is here --

There are a few options here, as discussed at http://stackoverflow.com/questions/1716296/why-does-printf-not-flush-after-the-call-unless-a-newline-is-in-the-format-strin -- ignore the question; the newline has nothing to do with printf()'s behavior.

from duo_unix.

That makes sense to me, but I'm unable to correct the behavior. Adding a fflush(stdout) to __status_fn didn't change the behavior. Have you been able to successfully fix it?

What's especially odd is that changes to the __status_fn don't seem to have any effect after re-installing. For example, adding additional characters to the printf doesn't result in the additional characters being printed when authenticating. However, when I change the AUTOPUSH_MSG variable I can see that change during authentication. So I'm curious if the fflush change is actually in effect in __status_fn. Maybe some kind of shared library caching?

EDIT: Nvm, the status function gets set in pam_duo.c to __duo_status. I'll investigate more.

from duo_unix.

So, as stated above, the conversation function is set to __duo_status for pam_duo. I don't see any way to flush the PAM conversation buffer. Here (https://fossies.org/dox/Linux-PAM-1.2.1/pam__ext_8h.html) are the functions available to us.

All the PAM conversation functions end up using pam_vprompt, so we could try to do something clever, but that seems like a sizable time investment given the low impact of this bug. But, for example:

We could change pam_info((pam_handle_t *)arg, "%s", msg) to something like:

char *p = NULL;
pam_prompt((pam_handle_t *)arg, PAM_PROMPT_ECHO_OFF, &p, "");

But then we're prompted when we get the autopush message, so we have to hit enter to continue.

This made me curious why Ubuntu was working for me, but CentOS wasn't. I just checked the configuration on my Ubuntu machine and it was incorrect, after correcting it I see the same behavior.

from duo_unix.

Actually, this has been a known issue with pam_duo since its inception (although, we could debate the definition of "known issue" since I had to do a fair bit of digging to remind myself of the root cause.) It's documented in code comments here: https://github.com/duosecurity/duo_unix/blob/master/pam_duo/pam_duo.c#L186

To put it a bit more simply than that comment: this is an issue with the way that OpenSSH implements PAM authentication. Whenever it receives an info message from a PAM module, it simply appends it to an internal buffer. Only when the PAM module sends back some other message (i.e. tells sshd that authentication succeeded or failed, or that more user input is required) does sshd flush this output such that a user can actually see it. The relevant code appears to be here (for the most recent release tag of openssh-portable):
https://github.com/openssh/openssh-portable/blob/V_7_2_P2/auth-pam.c#L749

I don't know why you would've seen different behavior in the past. One explanation we've sometimes seen is that people have installed login_duo instead of - or even in addition to - pam_duo. (For example: if you had installed and set up both pam_duo and login_duo, but not installed the SELinux module that enables it to perform HTTPS requests, then the pam module would have "failed open" and immediately fallen through to login_duo, which does display messages in real time.) It may also be possible that certain distibution-patched versions of openssh behave differently, although I'd consider this unlikely.

In any case, there's really nothing we can do to fix this.

from duo_unix.