Hi, On Thu, Dec 17, 2015 at 5:45 PM, Wayne Davison <wa...@opencoder.net> wrote:
> On Thu, Dec 17, 2015 at 1:22 PM, Selva Nair <selva.n...@gmail.com> wrote: > >> (a) leave as is and document that challenge-response is incompatible with >> user and pass from file >> > > If people lean this way I think the code would still need to be changed to > fail instead of endlessly looping, sending bad answers back to the server. > Thanks for the comments. Yes, incompatible options can be made to trigger an error. But only for static-challenge, not with dynamic challenge as that is initiated by the server. The endless looping is due to "auth-retry interact", which means keep trying after auth failure. > > (b) prompt for the response from console in both dynamic and static cases >> > > That gets my vote, for what that's worth. > > Prompting from management works fine as long as auth-user-pass file is not >> set. >> > > I assume that would be something you'd fix (or make the program reject). > The current code does not prompt on the management interface for a > challenge/response if someone combines --management, > --management-query-passwords, and an auth-user-pass file. > Specifying management-query-passwords and a user-pass file is obviously ambiguous. Currently user-pass file takes precedence. So user/pass/response will not be queried from management if a user-pass file is specified. > Ultimately, though, I've switched over to a simple perl script I wrote > that runs a managed openvpn and gives me full control w/o using > --auth-user-pass (since the official release is not going to support > reading the challenge/response from a file). > Hard to justify the extra code needed to support response from file. If the response is like an OTP (ever changing), reading from file is hardly useful. For the unusual case of a fixed response, a determined user could make a user-pass file with password and response packed into one line as "SCRV1:base64:base64" (assuming static challenge). Selva
