GNOME Bugzilla – Bug 752354
Impossible to connect automatically without prompt with openconnect plugin
Last modified: 2020-11-12 14:33:01 UTC
AFAIK it only applies to openconnect plugin vpn connections Even when password and other connection data are kept, upon connection request network manager launches /usr/libexec/nm-openconnect-auth-dialog. On the opened dialog boxes everything is filled, only thing left to do for the user is to click ont the login button and the connection is established. This is a problem because we should be able to connect automatically from a command line with a "nmcli connection up" command. When "nm connection up" command is run, it fails in one of thes two ways: 1 - without X: [root@myhost ~]# nmcli connection up myconnection Error: Connection activation failed: no valid VPN secrets. 2 - with X: it launches the nm-openconnect-auth-dialog and waits for the user to click on the login button Provided with all the auth and connecion data networkmanager should be able to start the openconnect vpn without interaction.
This thing is so annoying! I beg you, please, do something about it!
There are two parts to this. Firstly, if the standard GUI auth-dialog is running, it ought to "notice" if it already has all the information needed for the authentication form (the username and the password, often), and it should automatically submit the form instead of waiting for the user to hit the button. There is some complexity here. The requesting of the password from gnome-keyring is asynchronous, so it only turns up later — we'd have to check and potentially submit the form at *that* moment, if all fields are now populated. Also, it's very important not to *keep* trying this because we could cause accounts to get locked out. We'd need to stop after a single attempt. All of that is feasible, but nobody has been *sufficiently* annoyed by it so far that they've actually submitted a patch. But all of that is still only helpful in your 'with X' case. The auth-dialog would actually pop up, automatically do its thing, then go away again. It doesn't solve the 'without X' case at all. We do actually want a TUI auth-dialog, somehow integrated with or spawned by nmcli as it makes connections (there's a bug for that somewhere too). And that auth-dialog would obviously want the same automatic submission behaviour.
Could you please shed some light on the necessity of this auth-dialog? OpenVPN and VPNC plugins have their username and password settings right in the configuration UI and both work fine with and without X (since they don't need this extra prompt).
For AnyConnect (and newly-supported Juniper Network Connect) VPNs, the connection is made over HTTPS (initially, before the UDP transport kicks in), and it works in two phases. First you interact with the service to authenticate, receiving HTML or XML forms and submitting responses. Typically it'll ask you for a username and a password. It could be *arbitrary* stuff though. For Juniper we're at the point of actually wanting a full HTML renderer like Webkit in the UI for this, while AnyConnect makes do with a relatively simple set of choice/text/password input types. One user reports that at this stage, he gets a phone call and a number is automatically read to him, which he needs to type into the dialog box and submit. When your authentication is complete, you are rewarded with an HTTP cookie which represents your session. In AnyConnect it's called 'webvpn'; for Juniper it's 'DSID'. At this point, all the stuff which might require user interaction is done. So the "secrets" which the auth-dialog provides to the underlying NM service are threefold: - the session cookie (webvpn/DSID) - The address of the server it ended up on after any load-balancing redirects - The SSL certificate hash of that server The last is needed because it can prompt you to accept an unknown certificate too, and it has no way of doing *that* once it's passed off to the backend either.
Now that we have a facility for the back end to ask for "more secrets" instead of needing them all to be provided up-front, perhaps it's possible to revisit this historical design decision. Maybe the back end could take care of all the actual communication with the server, and only pass the specific requests for user interaction, out to the auth-dialog. I'm unlikely to spend time on this myself but I wouldn't object to someone else doing so. Bear in mind that you'll need to cope with SSL client certificates which are currently available to the *user* not necessarily to root, and make sure you cope with the Juniper requirements too.
bugzilla.gnome.org is being shut down in favor of a GitLab instance. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).