Packages: openconnect: Suggestion for dealing with 2FA

[marcosscriven]

Hi

I've gone from using the official AnyConnect OS X client, to using openconnect directly on my mac, to finally now using openconnect on an OpenWRT VM. The reason being I got so fed up with openconnect not properly cleaning up after itself, and my DNS/routing being messed up.

Anyway, the particular use case I need asks for two passwords - the first one is your regular VPN password, the second is just a short string to describe which 2-factor method you'd like to use. E.g push to use the Duo client, sms to get a text and so forth.

I was able to get this working in OpenWRT openconnect just by:

1. Setting password with a \n literal. E.g mypassword\npush
2. Patching openconnect.sh to drop the --non-inter option
3. Patching openconnect.sh to either use printf or echo -e to correctly interpret the literal.

My questions are thus:

1. How can we get this fix into upstream? Should we first submit a patch to openconnect to get multiple passwords working in non-inter mode? It's a particularly irksome one, in that it just stops without explaining that it's because non-inter mode is on, and input has been requested (even though when redirecting two lines to stdin it works without interaction anyway).
2. Should we add a second password option, or just expect the user to do as I did concatenating them into one?
3. Does this need changes to a gui somewhere in OpenWRT as well?
4. What was the original reasoning for using netifd rather than directly?
5. I notice you append -vpn to the name chosen in the config, so one ends up with names like myvpn-vpn. Any reason for that? Why not just let the user decide the final iface name?

[nmav]

This "push" 2FA is new to me and I don't believe it was ever considered upstream. We'll have to check what is blocking the --non-inter option from reading the second password, then suggest a fix upstream.

[nmav]

Could you try the patch above? That should allow having two passwords separated by newline without removing the --non-inter option.

[marcosscriven]

@nmav Thanks - I'll give it a try!

Just to add for future ref, there's details on using second passwords here.

[marcosscriven]

@nmav - sorry for the delay. I've just been trying to build this in the background while getting on with other work. Even with an x86 target, it seems to want to compile an enormous toolchain, so it's taking longer than I expected to test this patch.

[nmav]

Np, if that works we only need to add configuration options for the second password. Btw, could you send me (in private) the output of openconnect --dump-http-traffic on the server that supports that duo?

[marcosscriven]

sure - I'm nearly there with compiling just the openconnect package, but gnutls isn't compiling. I note you updated it a couple of days ago https://github.com/openwrt/packages/commit/b3d2d64928f2940257f8e9ae740df5809e24aa09

checking for NETTLE... no
configure: error:
  ***
  *** Libnettle 3.1 was not found.

[nmav]

You may have to use a specific tag/branch. The current gnutls in master is for openwrt 15.05 which has nettle 3.1.

[marcosscriven]

@nmav - Unfortunately the patch didn't work - in fact it was a regression in the sense that even dropping tine --non-inter option didn't help anymore.

In the original (when I drop the non interactive mode), I saw:

Fri Jun 19 12:02:54 2015 daemon.notice netifd: vpn (8072): Please enter your username and password.
Fri Jun 19 12:02:54 2015 daemon.notice netifd: vpn (8072): Password:

Whereas at the same point now it just stops dead (with --non-inter on):

Fri Jun 19 12:09:54 2015 user.notice openconnect: bringing down openconnect

If I try the patched version without --non-inter, I get:

Fri Jun 19 11:59:29 2015 daemon.notice netifd: vpn (7330): Please enter your username and password.
Fri Jun 19 11:59:29 2015 daemon.notice netifd: vpn (7330): Password:
Fri Jun 19 11:59:29 2015 daemon.notice netifd: vpn (7330): fgets (stdin): Inappropriate ioctl for device
Fri Jun 19 11:59:29 2015 user.notice openconnect: bringing down openconnect

I shall post you the sanitized logs.

EDIT - Fixed some typos

[marcosscriven]

Just to add, I think it's worth making it clear that with my original solution of dropping -non-inter, I still didn't actually have to interact with it - it still connected without any interaction (other than me accepting the Duo request on my phone).

[nmav]

Let's focus on the case where the --non-inter flag is present to keep things simple. In my 2FA setup testing with openconnect from git and my patch it works. The logs that you sent stop before openconnect gets to even parse the username password form. Could it be some unrelated issue that caused the failure?

[nmav]

My guess is that the second prompt is not presented as password. The pull request above has been updated to handle that case as well.

[marcosscriven]

@nmav - thanks, that worked! Have emailed you the redacted logs.

[nmav]

Cool! I've enhanced the config to accept a password2 for these use cases.

[ventz]

Was this ever submitted upstream?

Trying to create an automated applet (for os x) that will pull the password from the keychain and deal with the "push" secondary password in order to generate the Duo push, and I can't seem to generate it correctly.

I have tried variations of:

1.) echo "password\npush" | openconnect .... --passwd-on-stdin --non-inter $host
vs
2.) "echo "password" && echo "push" | openconnect .... --passwd-on-stdin --non-inter $host

And a few others, but none seem to get past the:

Password:
***
User input required in non-interactive mode
Failed to obtain WebVPN cookie

[holms]

So how do you pass multiple password to openconnect? It doesn't work from examples above.

[ventz]

For anyone coming here -- here is the link to the project I ended up creating (GUI for Mac): https://github.com/ventz/openconnect-gui-menu-bar

[holms]

Thanks I use linux

[panaali]

So how do you pass multiple password to openconnect? It doesn't work from examples above.

@holms Maybe this works for you:

echo -e "${VPN_PASSWORD}\n${PUSH_OR_PHONE}\n" | openconnect ...

Based on @ventz implementation. Look here for more information.