unable to use RSA SecureID on Unbuntu 14.04 LTS 64 bit

[Mark Kolmar]

I updated the packages using the PPA. The VPN GUI (top right) works now. 
I appreciate your help very much with this issue, which is more 
complicated than maybe either of us would have expected.

I set up a VPN profile for the new gateway with RSA token manually 
entered. That seems to behave the same as the build of openconnect 6.00 
that I tested earlier from shell. The GUI doesn't have anywhere to enter 
the 2nd password, even assuming correct 1st password (derived from 
token). I will test again from the command line and using the newest 
source when I get a chance.

Unless openconnect can be told to require a 2nd password, and if it does 
not detect that the server expects additional user input, authentication 
will always fail. One complication is that the accounts lock out after 
very few failed attempts.

It looks like stoken (this build anyway) generates a 6-digit code that 
is almost an arithmetic sum of PIN+tokencode, not carried. That is, if I 
set the PIN to 0000, stoken generates the same tokencode as the RSA app. 
For the case I am dealing with, the first password is the prefix 
concatenated with the current tokencode. I gather that some VPN gateways 
must combine PIN and tokencode the way stoken does.

--Mark

On 8/3/2014 3:18 AM, Kevin Cernekee wrote:
> I have updated my PPA with new builds for Ubuntu 14.04:
>
> openconnect 6.00 (built from the released tarball)
> network-manager-openconnect 0.9.9.0~20140802 (git commit eaee7e917694eed)
> stoken 0.8~20140802 (git commit ba44603cd5816)
>
> These all seem to be working OK for me so far.  Of course, since I
> used the official 6.00 sources, there isn't support for the
> experimental "PIN prompt on PINless tokens" patch I posted earlier.
> You would need to replace your local libopenconnect.so.3 with the
> patched version to try that out.
>
> AFAICT, there is no "0.9.10" release of network-manager-openconnect
> yet.  Only NetworkManager.
>
> As for the auth handshake problem - I would suggest setting up a MITM
> proxy to see where AnyConnect and OpenConnect diverge.  That is how I
> debugged the initial XML POST growing pains.
>