GNOME Bugzilla – Bug 751842
Google authenticator passcode prompt.
Last modified: 2021-06-21 08:04:08 UTC
Hello Everyone, NetworkManager openvpn with google authentication never prompt for passcode. If I put password and passcode in one line together it just failing. Is possible add this feature. And from cli/shell openvpn works good.
What version of NetworkManager and NetworkManager-openvpn? Could you run nm-openvpn-service with the "--debug" and "--persist" options and get some debug log output? Something like this, depending on where nm-openvpn-service is on your distro: sudo killall -TERM nm-openvpn-service sudo /path/to/nm-openvpn-service --debug --persist then start the VPN connection sanitize the log (remove usernames, IP address, and any password stuff) and then either email it to me directly, or attach it here if you're comfortable with that.
Here paste with all debug http://fpaste.org/239211/43585235/ required password. Check IRC private msg
I have the same problem. Any progress on this?
(In reply to Roy Paterson from comment #3) > I have the same problem. Any progress on this? Hi, pastebin in comment 2 has expired and logs are not accessible anymore. Can you please grab logs as described and attach them to this BZ?
Created attachment 319138 [details] log file Note to self - partially redacted with regex: ^(.* (?:UDPv4|ACK|BIO|PO_CTL|I/O|TLS:|PID_TEST|PO_WAIT\[\d+,\d+\]|MTU|Socket Buffers|GETADDRINFO|Client pre_master:|Client random\d:|Server pre_master:|Server random\d:|tls1_(?:P_hash|PRF) (?:sec|seed|out|out\[\d+\]):|Master (?:En|De)crypt \(.*\):|(?:CIPHER|HMAC) KEY:)) .*$
Thanks for the response! Log attached - hopefully I didn't redact too much. The interesting bit appears to be: Fri Jan 15 09:35:14 2016 us=4093 AUTH: Received control message: AUTH_FAILED,CRV1:R,E:<redacted>:<redacted>:Enter Google Authenticator Code
(In reply to Roy Paterson from comment #6) > Thanks for the response! Log attached - hopefully I didn't redact too much. > The interesting bit appears to be: > > Fri Jan 15 09:35:14 2016 us=4093 AUTH: Received control message: > AUTH_FAILED,CRV1:R,E:<redacted>:<redacted>:Enter Google Authenticator Code I think at the moment NM openvpn plugin doesn't support dynamic challenge authentication, and so 2FA works only when the server requires a token concatenated to password.
I've heard conflicting reports about that - is that the definitive answer? NM openvpn plugin just doesn't support prompting for 2FA? That would be a bummer.
(In reply to Roy Paterson from comment #8) > I've heard conflicting reports about that - is that the definitive answer? > NM openvpn plugin just doesn't support prompting for 2FA? That would be a > bummer. Yes, it's not supported ATM.
*** Bug 752740 has been marked as a duplicate of this bug. ***
Also, from bug 752740: > Can I expand this bug to include support for "static-challenge" support as > well? Effectively we have exactly the same set-up, but instead of the > challenge-response method, we use the static-challenge method, but > essentially it the same, it'll just require an additional configuration > setting.
Please, could someone raise the priority of this? It's very annoying when NM openvpn does not support this because all the other settings a managed by NM as well (e.g. /etc/resolv.conf, custom routes, etc.) by now. Imho it would be enough if a configuration option (e.g. static-challenge) could be activated which creates an additional prompt for a static challenge just like the cli. See 'static-challenge' here: https://openvpn.net/index.php/open-source/documentation/miscellaneous/79-management-interface.html Even clients for mobile devices support this for a long time and it is easier to connect to a VPN server via phone than it is with the more mature NM-openvpn. I also doubt, that many VPN servers do NOT use 2FA already (at least none I know of). It's most likely that typical users will also mess with their e.g. resolv.conf and run openvpn as root from the cli because of this. Greetings, LR
Bump - i'm getting the same thing. in syslog: AUTH: Received control message: AUTH_FAILED,CRV1:R,E:somebase64string:anotherbase64string:Enter Google Authenticator Code SIGUSR1[soft,auth-failure] received, process restarting So the password is saved, and it looks like it's getting past the initial password. The server responds that the password was not correct, which is sort of misleading, but may be a hacky way of implementing this for backwards compatibility. Normally if the saved password is rejected, the client should prompt a user to enter the password again instead of trying the same thing repeatedly. Interestingly, if i intentionally enter the wrong password into NetworkManager, I see the same behavior: AUTH: Received control message: AUTH_FAILED SIGUSR1[soft,auth-failure] received, process restarting There is no prompt, it just keeps trying the same password. This is also dangerous because it could trigger some sort of brute force measures. Put up a bounty here: https://www.bountysource.com/issues/29589637-google-authenticator-passcode-prompt
Created attachment 348839 [details] [review] Patch to implement dynamic challenge response protocol Here's a patch. (I sent it also to the mailing list but it seems there is some delay or filtering going on.) I've tested this with a normal SMS based 2FA setup on both - git HEAD 293d7a94fc6b86b0f0320cbeac5595ff9d4eace5 and - network-manager-openvpn 1.2.8-2 from Debian unstable Can you test this with "Google authenticator"?
Thank you for the patch. Applied to the git master: https://git.gnome.org/browse/network-manager-openvpn/commit/?id=5b96fecb97c752e08fdcebb331b983196f4b8935
Lubomir, thanks! Is using NM_OPENVPN_KEY_PASSWORD ok here or should we have a new hint for the challenge response? (like we already have NM_OPENVPN_KEY_HTTP_PROXY_PASSWORD and NM_OPENVPN_KEY_CERTPASS)
(In reply to Timo Lindfors from comment #16) > Lubomir, thanks! Is using NM_OPENVPN_KEY_PASSWORD ok here or should we have > a new hint for the challenge response? (like we already have > NM_OPENVPN_KEY_HTTP_PROXY_PASSWORD and NM_OPENVPN_KEY_CERTPASS) Hi, I believe it's not ok to reuse NM_OPENVPN_KEY_PASSWORD for the challenge response. I pushed some commits do fix this to branch bg/dynamic-challenge-bgo751842. Any opinions?
Created attachment 356774 [details] [review] [NM-PATCH] all: support challenge secrets for VPNs Patch for NetworkManager daemon.
Thanks for taking a look into this. I was indeed not sure if re-using NM_OPENVPN_KEY_PASSWORD was ok for this. Do you need help testing the above patch?
(In reply to Beniamino Galvani from comment #18) > Created attachment 356774 [details] [review] [review] > [NM-PATCH] all: support challenge secrets for VPNs > > Patch for NetworkManager daemon. The patch is not very clear to me. Isn't the part in src/settings/nm-settings-connection.c an unrelated bugfix? Could you split it to a separate patch with a fool-proof description? :) This "x-vpn-challenge" is a new convention you made up now, isn't it? Can we change it to include a trailing dash ("x-vpn-challenge-") to enforce that the secret names are in that form? Is this only useful for VPN? I don't think it is. Maybe it should be just called "x-challenge-". Is this really the right approach? Can we not expand/use the secret-flags to encode this meaning? Is that because secrets_required_cb() in src/vpn/nm-vpn-connection.c only gets the name, but not any flags? To bad, the API there is so limited. Can you add a #define for "x-*challenge-" to libnm-core/nm-setting.h, and maybe a backport to shared/nm-utils/nm-vpn-plugin-macros.h (see "possibly missing defines from newer libnm API.").
(In reply to Thomas Haller from comment #20) > This "x-vpn-challenge" is a new convention you made up now, isn't it? Yes, to encode the special meaning of the secret in the name, so that we don't need to extend the API. > Is this really the right approach? Can we not expand/use the secret-flags to > encode this meaning? Is that because secrets_required_cb() in > src/vpn/nm-vpn-connection.c only gets the name, but not any flags? To bad, > the API there is so limited. Yes, the API is limited. However, we can extend it with a new SecretsRequiredWithFlags signal: https://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=bg/openvpn-challenge and use the new @flags arguments from the openvpn plugin to specify that the request is for a "one-time" secret that must be always asked to user (even if the connection doesn't have flags for it) and not stored: https://git.gnome.org/browse/network-manager-openvpn/log/?h=bg/dynamic-challenge-bgo751842 What do you think about this approach?
(In reply to Beniamino Galvani from comment #21) > What do you think about this approach? I like this approach in general. > vpn: add a SecretsRequiredWithFlags signal having a flags argument on a D-Bus method/signal seems in general good for future extensiblity. But for some reason, SecretsRequiredWithFlags's @secrets argument is a list of "secrets" (instead of asking for just one single secret). Not sure, why that is even needed, and whether SecretsRequiredWithFlags should not just request for one secret at a time. Anyway, probably we want to ask for multiple secrets. But then it seems to me that NM_VPN_PLUGIN_SECRETS_FLAG_ONE_TIME should be a flag per secret, not for the entire request. I mean: - <arg name="secrets" type="as" direction="out"/> + <arg name="secrets" type="a{su}" direction="out"/> But it's tricky. The nm_settings_connection_get_secrets() API is odd. It doesn't really ask for the "secrets", instead the "secrets" are added to the "hints" list. Look at nm_vpn_get_secret_names(). nmcli cannot just ask for arbitrary secrets, it *knows* which secrets openvpn supports ("password", "cert-pass", "http-proxy-password"). By that reasoning, the client could very well know that "challenge" has certain one-time behavior. Likewise, nm-applet can only handle secrests via the libnm VPN plugin (which again knows which secrets are supported). I wish, this whole secret API would be generic and allow to request secrets without requiring nmcli to understand the VPN service type. As such, I like SecretsRequiredWithFlags or the "x-challenge-" prefix. But it seems to me, it doesn't go far enough. Lubomir was looking at the secret API too. I wish we could improve the secret API, but it seems a larger effort.
A comment toward the functional part of this issues rather than the implementational... In some cases (not sure how or why, but possibly depending on auth mechanism somewhere) the challenge/response query that openvpn prompts for differs: The patch mentioned here seems to work with a prompt like this: >PASSWORD:Verification Failed: 'Auth' ['CRV1:flags:state_id:username:text'] Whereas I'm currently getting: AUTH_FAILED,CRV1:R,E:93NBZNaOH799HLoxv7tWefldc8JtIpbf:eHRod3Q=:Enter PASSCODE In my case I'm connecting to an OpenVPN-AS setup with SMSPASSCODE integration. Would it be possible to expand the patch to accommodate for this situation as well?
Your message is in the expected format I think. I get Fri Oct 27 18:32:58 2017 AUTH: Received control message: AUTH_FAILED,CRV1:R,E:C9[CENSORED]:bGluZGk=:Enter [CENSORED] and it works. There must be some other reason why it is failing.
Hmm, that's strange. It works perfectly in the cli but through Network-Manager it appears to retry the main authentication. I'm on: openvpn 2.4.3-4ubuntu1 network-manager 1.8.4-1ubuntu3 network-manager-gnome 1.8.4-1ubuntu3 network-manager-openvpn 1.2.10-0ubuntu2 network-manager-openvpn-gnome 1.2.10-0ubuntu2
Just a note on this issue: I've added a new bounty to this bug on bountysource.com: https://www.bountysource.com/issues/29589637-google-authenticator-passcode-prompt. Obviously the ticket has been re-opened since the original bounty was paid out. I'm working to convince a team to move to linux-based development environments. One of the big blockers is that we're using OpenVPN Application Server and we have the google 2fa turned on. I'm using Ubuntu 17.10 with Gnone 3.26, and this is still not functional. I'm willing to help test any patches and fixes. This seems like a very critical piece of functionality that would benefit a large part of our community.
Created attachment 362901 [details] [review] fix 2fa handle_management_socket string parsing bug I found a trivial mistake in one get_detail() function call, where rather than passing "str" variable as the input string, "auth", which already keeps the result from the previous get_detail() call, is used, and so failure_reason will always get NULL, rendering it impossible for parse_challenge() to succeed.
(In reply to Adam Koczur from comment #27) > Created attachment 362901 [details] [review] [review] > fix 2fa handle_management_socket string parsing bug master: https://git.gnome.org/browse/network-manager-openvpn/commit/?id=712e360eb8164731331dec4f4002d3612fa4dfce nm-1-2: https://git.gnome.org/browse/network-manager-openvpn/commit/?id=7f18691ec3e04c900a1e96440b0a95cc4b33f699 Thanks!
Adam, thanks for spotting the error! I'm also migrating people to network-manager-openvpn and am happy to help in testing any future patches if that can help. I think the main bug in the current implementation is that if you enable the "save password" feature the 2FA token will overwrite the saved password :)
The bug got reopened, and a follow-up fix was merged. Is there anything missing on latest master? (In reply to Timo Lindfors from comment #29) > I think the main bug in the current implementation is that > if you enable the "save password" feature the 2FA token will overwrite the > saved password :) That sounds like a separate issue. Can we close this bug, and open new bugs for missing features/ill-behaviors? It's unclear with this wall of text, what is actually missing. Ok, I go ahead and close it again. But please do re-open if you have issues to report. Or maybe better open a new bug with a fresh description of the issue. thanks!!
I'm sorry, these questions probably don't really belong here, but I'd appreciate your help. When would a fix like this get released? I tried to build my own from source, but I'm getting the following now: Jan 10 00:08:01 sander-laptop NetworkManager[1004]: <info> [1515571681.8234] vpn-connection[0x55b28b804100,7bae33ff-1b94-44d8-bcfa-9920c8f907c7,"Skyward",0]: VPN service disappeared Jan 10 00:08:01 sander-laptop NetworkManager[1004]: <info> [1515571681.8268] vpn-connection[0x55b28b804100,7bae33ff-1b94-44d8-bcfa-9920c8f907c7,"Skyward",0]: VPN connection: (ConnectInteractive) reply received Jan 10 00:08:01 sander-laptop NetworkManager[1004]: <warn> [1515571681.8272] vpn-connection[0x55b28b804100,7bae33ff-1b94-44d8-bcfa-9920c8f907c7,"Skyward",0]: VPN connection: failed to connect interactively: 'Message recipient disconnected from message bus without replying' Is there a good place that documents how to build and install this from source, because I feel I had a lot of room for error there/
Sounds to me like the problem in comment #29 might be the result of reusing NM_OPENVPN_KEY_PASSWORD for the TOTP code? Can't claim to be too familiar with the code, so apologies if this does not apply. I'm struggling with this exact problem on 1.30 using network-manager-openvpn 1.8.12.