Comments (8)
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 --
Lines 80 to 84 in 0ee434d
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.
Related Issues (20)
- Feature request: default PAM / authselect profiles HOT 4
- Critical Vulnerability: Default Configuration Can Leave Unenrolled Accounts (Including 'root') Exposed HOT 3
- AD Users are bypassed due to groups when groups config option is set, regardless of group. HOT 4
- RHEL 9 / Centos 9 are missing in repo HOT 2
- Are there any tips as to how to get NetDrive or SSHFS to work with pam_duo? HOT 2
- Autopush should be configurable by device, not globally HOT 2
- login_duo: no selection output and automatically pushes to first phone in list with eternal terminal HOT 2
- duo_unix-1.12.1-4.el8 and setuid HOT 3
- Duo Unix 2.x RPM Digests on RHEL 8 with FIPS enabled HOT 7
- Feature request: behavior in situation of missing conf file and not member of groups directive HOT 4
- Bbbb
- More of a feature request, would like to have ,push# implemented like the Fortinet VPN module has HOT 2
- PAM_SUCCESS returned for non-duo users instead of PAM_IGNORE HOT 8
- /usr/sbin/login_duo returning no such file or directory after fresh install of duo HOT 1
- Manpages (login_duo/login_duo.8, pam_duo/pam_duo.8) hardcodes /etc instead of adjusting path according to --prefix
- Choice of the second factor should have a default value
- 8.8.8.8 DNS Server is hardcoded
- duo_unix not working with openssl 3.0.8 HOT 4
- Order of DUO Devices Displayed Incorrectly for Users with 10 or More Devices HOT 3
- Duo UNIX PAM module failing on AIX
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from duo_unix.