Two-factor authentication

[schlatterbeck]

One of my customers has recently switched to two-factor auth using a security-token. When connecting with the official client it asks for a second password after the first. With openfortivpn I'm getting Fri Dec 16 12:08:18 2016 daemon.err openfortivpn[7389]: Could not authenticate to gateway (Bad HTTP response code). (this message with my patch to allow log-output to syslog, see open pull request #65) Are you interested in making 2-factor auth work and help me debug & patch openfortivpn? I'd guess my first step would be to print the http response in the step that fails above...

Ralf

[dsgwork]

@schlatterbeck yes please provide the HTTP requests/responses during the authentication phase (minus any sensitive information of course). It should help to diagnose what's going wrong.

The interesting code here is in the auth_log_in function in src/http.c. Please check if it's the first or second header check (i.e., before or during two-factor auth) that's returning ERR_HTTP_BAD_RES_CODE.

If there's nothing obvious that jumps out from that info, it would also be very useful to have the HTTP requests/responses from the official fortinet client when connecting to the same VPN. For example, there's two code fields (code= and code2=). Since I have no idea what code2= is supposed to convey and it wasn't used in the VPNs I tested with when adding the two-factor support, we send it empty. Perhaps your gateway is expecting some data there? Having the dialog from the official client to compare should help determine that.

[adrienverge]

@dsgwork Thanks for taking care of this :)

(I don't have access to a Fortinet VPN anymore)

[schlatterbeck]

On Fri, Dec 16, 2016 at 04:28:29AM -0800, Dav�� Steinn Geirsson wrote:

@schlatterbeck yes please provide the HTTP requests/responses during the authentication phase (minus any sensitive information of course). It should help to diagnose what's going wrong.

The interesting code here is in the auth_log_in function in src/http.c. Please check if it's the first or second header check (i.e., before or during two-factor auth) that's returning ERR_HTTP_BAD_RES_CODE.

Thanks for the pointer.

I'm now debugging this in gdb. The error appears in the first header check. I'm getting (I've replace possibly sensitive fields with ):

HTTP/1.1 401 Authorization Required Content-Length: 1348 Keep-Alive: timeout=5, max=1000 Connection: Keep-Alive Cache-Control: no-cache Content-Type: text/html

Please enter your passcode (primary: One-Time Password): Answer:

So I guess this is fairly obvious that at this point we should ask the user for the one-time password and submit this to /remote/logincheck > If there's nothing obvious that jumps out from that info, it would > also be very useful to have the HTTP requests/responses from the > official fortinet client when connecting to the same VPN. How would you debug the original client? I've used an ssl mitm proxy in the past, but maybe there's an easier way? Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting www: http://www.runtux.com Reichergasse 131, A-3411 Weidling email: office@runtux.com

[schlatterbeck]

Looks like I can implement the otp support with the info I have so far, if I encounter further problems, I'll let you know.

It would be helpful if you could merge my syslog patch as I'm working with the patched version currently (and adding a one-time-password option will probably collide with the changes I've already made). Github makes it quite difficult to have several outstanding pull requests....

Thanks Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting www: http://www.runtux.com Reichergasse 131, A-3411 Weidling email: office@runtux.com

[dsgwork]

This is interesting. Looks like this is a different method of two-factor authentication. I guess these are physical tokens giving you the second factor?

The two-factor setups I've worked with were SMS-based, so the second factor authentication SMS is only delivered after the initial call to /remote/logincheck, and the client then calls it again with the received token once it's been delivered.

In this case it seems the token and password are both requested at the same time. As you say, the expected behaviour is obvious (just stuff the token into the magic= parameter in the first call to /remote/logincheck).

A quick-and-dirty hack to let the client ask for the 2FA code and stuff it into the first call should be easy to do, and would allow you to connect. A proper patch fit for upstreaming would likely need to change the auth_log_in function to parse the response body from the first call, see if there is an input field in the form with NAME="magic" and if so, request 2FA code and add it to the second call. I don't think there's any plumbing for this, as we currently only look at the HTTP headers during this stage. This isn't terribly difficult, but I don't expect I'll have time to make a patch in a reasonable timeframe these days (and since I don't have access to any VPNs with a similar setup, I couldn't test it either). If you can cook something up that would be great!

How would you debug the original client? I've used an ssl mitm proxy in the past, but maybe there's an easier way?

Unfortunately no, IIRC I used stunnel as a SSL MitM proxy last time I needed to do this. But I think in this case it's not needed, as we have a clear idea of what needs to be done on the client side. Just need someone to make the proper modifications.

[schlatterbeck]

On Fri, Dec 16, 2016 at 08:35:33AM -0800, Dav�� Steinn Geirsson wrote:

This is interesting. Looks like this is a different method of two-factor authentication. I guess these are physical tokens giving you the second factor? Yes, this is a physical token claiming compatibility with RFC 6238 (TOTP)

In this case it seems the token and password are both requested at the same time. As you say, the expected behaviour is obvious (just stuff the token into the magic= parameter in the first call to /remote/logincheck).

No, I think the correct parameter is "credential". The magic seems to be there to provide context between the first and the second auth. Note that what I sent you is the output after the first password was already sent.

A quick-and-dirty hack to let the client ask for the 2FA code and stuff it into the first call should be easy to do, and would allow you to connect. A proper patch fit for upstreaming would likely need to change the auth_log_in function to parse the response body from the first call, see if there is an input field in the form with NAME="magic" and if so, request 2FA code and add it to the second call. Yes, that's basically what I'm planning to do. Note that I would add all the hidden input fields plus the text-input field 'credential'.

I don't think there's any plumbing for this, as we currently only look at the HTTP headers during this stage. This isn't terribly difficult, but I don't expect I'll have time to make a patch in a reasonable timeframe these days (and since I don't have access to any VPNs with a similar setup, I couldn't test it either). If you can cook something up that would be great! Yes, I'll try to come up with a patch for this, I need it myself :-)

Unfortunately no, IIRC I used stunnel as a SSL MitM proxy last time I needed to do this. But I think in this case it's not needed, as we have a clear idea of what needs to be done on the client side. Just need someone to make the proper modifications. Yep, I just wanted to make sure I understood how you would do this (and maybe add something new to my toolbox :-) I was using mitmproxy last time I did something like this.

Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting www: http://www.runtux.com Reichergasse 131, A-3411 Weidling email: office@runtux.com

[schlatterbeck]

Dav��, Adrien, I've implemented the token-based one-time password. I can successfully open a connection by either specifying --otp= or specifying the token output on the OTP password prompt.

Code is on my fork at https://github.com/schlatterbeck/openfortivpn

It would be nice if my last pull request (syslog support) would be merged first, that avoids conflicts when I need to rebase.

You may want to take a look first and tell me if you think I should amend the code before opening a pull request.

Thanks Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting www: http://www.runtux.com Reichergasse 131, A-3411 Weidling email: office@runtux.com

[adrienverge]

Hi Ralf,

I had a look to your code and it doesn't look bad.

Since I've never used these new authentication methods (2FA, OTP...) with Fortinet VPNs, I'd really like to hear what other contributors think of your OTP change.

Especially, we must make sure it does not break behavior for older regular VPNs (I'm thinking about src/http.c at line 494).

[dsgwork]

Hi all,

Finally got my VPN sorted again (password had expired so I couldn't test before). I can confirm the SMS-based 2FA authentication still works with the patch applied.

Code looks good to me, :+1: for inclusion :)

[schlatterbeck]

On Wed, Dec 21, 2016 at 05:16:10AM -0800, Dav�� Steinn Geirsson wrote:

Hi all,

[...] Code looks good to me, :+1: for inclusion :)

Thanks!

I've opened pull-request #84 after rebasing and then fixed non-passing checks (code formatting issues).

On Tue, Dec 20, 2016 at 03:14:16AM -0800, Adrien Verg� wrote:

Especially, we must make sure it does not break behavior for older regular VPNs (I'm thinking about src/http.c at line 494).

I'm now comparing the http response-code. Previously at that point if we didn't get "HTTP/1.1 200 OK" we would fail altogether. Now if we get 401 Auth required we try otp auth. I don't see any problems here, previously we would have already failed at that point. The worst thing that could happen is that someone without otp auth mistypes the password and then gets an otp prompt. But I don't know how the server would react to a wrong password.

Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting www: http://www.runtux.com Reichergasse 131, A-3411 Weidling email: office@runtux.com

[schlatterbeck]

On Wed, Dec 21, 2016 at 03:40:02PM +0100, Ralf Schlatterbeck wrote:

I'm now comparing the http response-code. Previously at that point if we didn't get "HTTP/1.1 200 OK" we would fail altogether. Now if we get 401 Auth required we try otp auth. I don't see any problems here, previously we would have already failed at that point. The worst thing that could happen is that someone without otp auth mistypes the password and then gets an otp prompt. But I don't know how the server would react to a wrong password.

I've now tested this with a wrong password (for the first password authentication). I'm not getting an otp password prompt but instead openfortivpn dies with the log message

Wed Dec 21 14:41:55 2016 daemon.err openfortivpn[7529]: Could not authenticate to gateway (No cookie given).

So I guess I didn't break anything for other users. (The error message could be better but that's what the server is sending we don't have much influence on this).

Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting www: http://www.runtux.com Reichergasse 131, A-3411 Weidling email: office@runtux.com

[fretn]

I tried to connect with openfortivpn to a fortisslvpn which has 2FA enabled through a radius server and it fails to connect, this is the console output:

[fretn@latika ~]$ sudo openfortivpn vpn.host.com:443 -vvv -u username -p password --trusted-cert fb4d377259083b5b606da9a46ab3bac569bc96a14a8cc5c509bc35d563fd198b3
WARN:   You should not pass the password on the command line. Type it interactively or use a config file instead.
WARN:   Bad port in config file: "0".
DEBUG:  Loaded config file "/usr/local/Cellar/openfortivpn/1.6.0/etc/openfortivpn/config".
DEBUG:  Config host = "vpn.host.com"
DEBUG:  Config realm = ""
DEBUG:  Config port = "443"
DEBUG:  Config username = "username"
DEBUG:  Config password = "********"
DEBUG:  server_addr: 123.124.125.126
DEBUG:  server_port: 443
DEBUG:  gateway_addr: 123.124.125.126
DEBUG:  gateway_port: 443
DEBUG:  Gateway certificate validation failed.
DEBUG:  Gateway certificate digest found in white list.
INFO:   Connected to gateway.
Please enter one-time password:
DEBUG:  Error reading from SSL connection (Protocol violation with EOF).
DEBUG:  server_addr: 123.124.125.126
DEBUG:  server_port: 443
DEBUG:  gateway_addr: 123.124.125.126
DEBUG:  gateway_port: 443
DEBUG:  Gateway certificate validation failed.
DEBUG:  Gateway certificate digest found in white list.
DEBUG:  Cookie: SVPNCOOKIE=kbvtdDj0LpMyEGClFOZpCmPGPhj/Wf5j3lzB/Yt4wGtQsYBy1Kx1C96ObRaF1XG20cSk4OF989paCVYpBfrBWNZta0RT0JyFjQy+yQrFxIoZ2e0cmbjlwAlzLN59Yjx9aZkyWLP9pkwXVM5qDTy9QFbAGI7Fr2ewBCOlqXCu/IntIW2V3d31sHnMCh/83HTZj67M2AWJp/PZspdm4tEE/xg==
INFO:   Authenticated.
DEBUG:  Cookie: SVPNCOOKIE=kbvtdDj0LpMyEGClFOZpCmPGPhj/Wf5j3lzB/Yt4wGtQsYBy1Kx1C96ObRaF1XG20cSk4OF989paCVYpBfrBWNZta0RT0JyFjQy+yQrFxIoZ2e0cmbjlwAlzLN59Yjx9aZkyWLP9pkwXVM5qDTy9QFbAGI7Fr2ewBCOlqXCu/IntIW2V3d31sHnMCh/83HTZj67M2AWJp/PZspdm4tEE/xg==
INFO:   Remote gateway has allocated a VPN.
DEBUG:  server_addr: 123.124.125.126
DEBUG:  server_port: 443
DEBUG:  gateway_addr: 123.124.125.126
DEBUG:  gateway_port: 443
DEBUG:  Gateway certificate validation failed.
DEBUG:  Gateway certificate digest found in white list.
DEBUG:  pppd_read_thread
DEBUG:  ssl_read_thread
DEBUG:  ssl_write_thread
DEBUG:  if_config thread
ERROR:  Received bad header from gateway:
  (hex) 48 54 54 50 2f 31 2e 31 20 34 30 33 20 46 6f 72 62 69 64 64 65 6e 0d 0a 44 61 74 65 3a 20 46 72 69 2c 20 31 33 20 41 70 72 20 32 30 31 38 20 30 38 3a 30 35 3a 32 36 20 47 4d 54 0d 0a 53 65 72 76 65 72 3a 20 78 78 78 78 78 78 78 78 2d 78 78 78 78 78 0d 0a 54 72 61 6e 73 66 65 72 2d 45 6e 63 6f 64 69 6e 67 3a 20 63 68 75 6e 6b 65 64 0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74 65 78 74 2f 68 74 6d 6c 0d 0a 58 2d 46 72 61 6d 65 2d 4f 70 74 69 6f 6e 73 3a 20 53 41 4d 45 4f 52 49 47 49 4e 0d 0a 43 6f 6e 74 65 6e 74 2d 53 65 63 75 72 69 74 79 2d 50 6f 6c 69 63 79 3a 20 66 72 61 6d 65 2d 61 6e 63 65 73 74 6f 72 73 20 27 73 65 6c 66 27 0d 0a 58 2d 58 53 53 2d 50 72 6f 74 65 63 74 69 6f 6e 3a 20 31 3b 20 6d 6f 64 65 3d 62 6c 6f 63 6b 0d 0a 0d 0a 36 36 61 20 20

  (raw) HTTP/1.1 403 Forbidden.
Date: Fri, 13 Apr 2018 08:05:26 GMT.
Server: xxxxxxxx-xxxxx.
Transfer-Encoding: chunked.
Content-Type: text/html.
X-Frame-Options: SAMEORIGIN.
Content-Security-Policy: frame-ancestors 'self'.
X-XSS-Protection: 1; mode=block.
.
66a 
[fretn@latika ~]$

[DimitriPapadopoulos]

@fretn Which version of openfortivpn are you running? Vanilla 1.6.0 or the latest version available from git?

[mrbaseman]

I was looking into this, too, and it's quite strange. It already sais "INFO: Remote gateway has allocated a VPN." and even goes into io_loop as we can see at the startup of the pthreads, and at this point suddenly the ssl_read thread receives a HTTP/1.1 403 Forbidden header. So, in run_tunnel we have already reached io_loop around here I was thinking if this could be a timing issue with the threads, but all the authentication stuff happens already before threads come into play.

[DimitriPapadopoulos]

By the way is this message to be expected? DEBUG: Error reading from SSL connection (Protocol violation with EOF).

[fretn]

@DimitriPapadopoulos latest one in homebrew (macos) Vanilla 1.6.0

and now I just tried git version on linux and it fails too, see below

[frlae@modimo openfortivpn]$ sudo ./openfortivpn vpn.host.com:443 -vvv -u username -p 'password' --trusted-cert fb4d377259083b5b606da9a46ab3a4066bc96a14a8cc5c509bc35d563fd198b3
WARN:   You should not pass the password on the command line. Type it interactively or use a config file instead.
WARN:   Could not load config file "/usr/local/etc/openfortivpn/config" (No such file or directory).
DEBUG:  Config host = "vpn.host.com"
DEBUG:  Config realm = ""
DEBUG:  Config port = "443"
DEBUG:  Config username = "username"
DEBUG:  Config password = "********"
DEBUG:  server_addr: 123.124.125.126
DEBUG:  server_port: 443
DEBUG:  gateway_addr: 123.124.125.126
DEBUG:  gateway_port: 443
DEBUG:  Gateway certificate validation failed.
DEBUG:  Gateway certificate digest found in white list.
INFO:   Connected to gateway.
Please enter one-time password:
DEBUG:  Error reading from SSL connection (Protocol violation with EOF).
DEBUG:  server_addr: 123.124.125.126
DEBUG:  server_port: 443
DEBUG:  gateway_addr: 123.124.125.126
DEBUG:  gateway_port: 443
DEBUG:  Gateway certificate validation failed.
DEBUG:  Gateway certificate digest found in white list.
DEBUG:  Cookie: SVPNCOOKIE=vtktdDj0LpMyEGClFOZpCmPGPhj/Wf5j3lzB/Yt4wGtQsYBy1Kx1C96ObRaF1XG20cSk4OF989paCVYpBfrBWNZta0RT0JyFjQy+yQrFxIoZ2e0cmbjlwAlzLN59Yjx9aZkyWLP9pkwXVM5qDTy9QFbAGI7Fr2ewBCOlqXCu/IntIW2V3d31sHnMCh/83HTZj67M2AWJp/PZspdm4tEE/bc==
INFO:   Authenticated.
DEBUG:  Cookie: SVPNCOOKIE=vtktdDj0LpMyEGClFOZpCmPGPhj/Wf5j3lzB/Yt4wGtQsYBy1Kx1C96ObRaF1XG20cSk4OF989paCVYpBfrBWNZta0RT0JyFjQy+yQrFxIoZ2e0cmbjlwAlzLN59Yjx9aZkyWLP9pkwXVM5qDTy9QFbAGI7Fr2ewBCOlqXCu/IntIW2V3d31sHnMCh/83HTZj67M2AWJp/PZspdm4tEE/bc==
INFO:   Remote gateway has allocated a VPN.
DEBUG:  server_addr: 123.124.125.126
DEBUG:  server_port: 443
DEBUG:  gateway_addr: 123.124.125.126
DEBUG:  gateway_port: 443
DEBUG:  Gateway certificate validation failed.
DEBUG:  Gateway certificate digest found in white list.
DEBUG:  pppd_read thread
DEBUG:  ssl_write thread
DEBUG:  ssl_read thread
DEBUG:  if_config thread
ERROR:  Received bad header from gateway:
  (hex) 48 54 54 50 2f 31 2e 31 20 34 30 33 20 46 6f 72 62 69 64 64 65 6e 0d 0a 44 61 74 65 3a 20 46 72 69 2c 20 31 33 20 41 70 72 20 32 30 31 38 20 30 39 3a 32 39 3a 33 36 20 47 4d 54 0d 0a 53 65 72 76 65 72 3a 20 78 78 78 78 78 78 78 78 2d 78 78 78 78 78 0d 0a 54 72 61 6e 73 66 65 72 2d 45 6e 63 6f 64 69 6e 67 3a 20 63 68 75 6e 6b 65 64 0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74 65 78 74 2f 68 74 6d 6c 0d 0a 58 2d 46 72 61 6d 65 2d 4f 70 74 69 6f 6e 73 3a 20 53 41 4d 45 4f 52 49 47 49 4e 0d 0a 43 6f 6e 74 65 6e 74 2d 53 65 63 75 72 69 74 79 2d 50 6f 6c 69 63 79 3a 20 66 72 61 6d 65 2d 61 6e 63 65 73 74 6f 72 73 20 27 73 65 6c 66 27 0d 0a 58 2d 58 53 53 2d 50 72 6f 74 65 63 74 69 6f 6e 3a 20 31 3b 20 6d 6f 64 65 3d 62 6c 6f 63 6b 0d 0a 0d 0a 36 36 61 20 20

  (raw) HTTP/1.1 403 Forbidden.
Date: Fri, 13 Apr 2018 09:29:36 GMT.
Server: xxxxxxxx-xxxxx.
Transfer-Encoding: chunked.
Content-Type: text/html.
X-Frame-Options: SAMEORIGIN.
Content-Security-Policy: frame-ancestors 'self'.
X-XSS-Protection: 1; mode=block.
.
66a 
INFO:   Cancelling threads...
DEBUG:  Waiting for pppd to exit...
DEBUG:  waitpid: pppd terminated by signal 1
ERROR:  pppd: terminated by signal: Hangup
INFO:   Terminated pppd.
INFO:   Closed connection to gateway.
DEBUG:  server_addr: 123.124.125.126
DEBUG:  server_port: 443
DEBUG:  gateway_addr: 123.124.125.126
DEBUG:  gateway_port: 443
DEBUG:  Gateway certificate validation failed.
DEBUG:  Gateway certificate digest found in white list.
INFO:   Logged out.
[frlae@modimo openfortivpn]$

[DimitriPapadopoulos]

Have you perhaps tried the proprietary FortiClient and if so does it work?

[fretn]

very good point, the proprietary client doesn't work either, it worked in the beginning of the week, so nevermind above messages, something else is going on

[DimitriPapadopoulos]

Here are a few similar issues found online:

• SSL-VPN not working
• Bad header from gateway (403 Forbidden)

Looks like an issue with the FortiGate device. Not sure how to improve the error message though. Perhaps it would help if you could show us the error displayed by FortiClient.

[mrbaseman]

It makes sense now, @fretn you had the permission to access the web portal, but you didn't have the permission to open a tunnel. Mapping the permissions to groups/users sometimes is difficult to understand. I once couldn't log in until I have added a firewall rule that allowed me to access anything. My interpretation was that if FortiOS notices that a particular account has no permissions to access any location on any network, it optimizes the account away and doesn't even allow it to log in.

For the record, if all the authentication stuff works and establishing the ppp tunnel fails with a 403 Forbidden it's probably due to the missing permission to open a tunnel.

[fretn]

Yes that was indeed the issue. I didn’t try that specific user with the official client, I only tried the portal. Sorry for wasting your time

[thackel]

The OTP support is somehow working: '''-o foobar''' and then i get asked for the real token '''Two-factor authentication token:''' So i don't provide the current token on the command line, i just activate OTP by using the switch.

Is it possible to switch it on via configuration file?

[schlatterbeck]

On Tue, May 08, 2018 at 02:37:12PM +0000, Thomas Hackel wrote:

The OTP support is somehow working: '''-o foobar''' and then i get asked for the real token '''Two-factor authentication token:''' So i don't provide the current token on the command line, i just activate OTP by using the switch.

I'm using it by specifying the real second-factor token on the command line, e.g.

openfortivpn --otp 12345

Is it possible to switch it on via configuration file? The -o or --otp option is meant to provide the actual token not switch on a prompt for a second authentication token. At least I'm using it that way. So it doesn't make much sense to put it in the config file.

That said I think if the remote site asks for a second token and you didn't specify it on the command line it would prompt you for it, not sure though.

Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting www: http://www.runtux.com Reichergasse 131, A-3411 Weidling email: office@runtux.com

[thackel]

Something is different then.

• Server is using OTP.
• Without "--otp foobar" there is no prompt for the token.
• When i use "--otp VALIDTOKEN" i get asked for the token and use the same VALIDTOKEN as on the command line to establish the connection.

So it does not matter what i provide after "--otp", for me it just somehow activates the prompt.

[schlatterbeck]

On Fri, May 11, 2018 at 06:43:52AM -0700, Thomas Hackel wrote:

Something is different then.

• Server is using OTP.
• Without "--otp foobar" there is no prompt for the token.
• When i use "--otp VALIDTOKEN" i get asked for the token and use the same VALIDTOKEN as on the command line to establish the connection.

So it does not matter what i provide after "--otp", for me it just somehow activates the prompt.

Interesting. I'm not using the very latest version, so something might have changed. For me I'm specifying

--otp

Note that I have a TOTP (one-time-token aka google authenticator) device that shows the one-time-token on a display when I press a button.

You may have a different authentication scheme where the token cannot be available at the start of the authentication, that may be the reason you get a second prompt. (I've seen auth schemas where you get the second password via a short message to your phone).

Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting www: http://www.runtux.com Reichergasse 131, A-3411 Weidling email: office@runtux.com

[choonge]

Same symptoms as @thackel here. I would expect that if --otp is provided as an argument, there should be no additional prompt for the token.

The current behaviour also makes it impossible to use the NetworkManager applet, since the applet does not create a GUI prompt for the token but (presumably, I have not read the code) adds the token as an argument instead.

Edit: FYI, we use the FortiGate phone app which generates tokens, so the token is available at the start of auth. But indeed, this may have something to do with server configuration still.

[DimitriPapadopoulos]

@choonge I suggest opening a new ticket. This issue has become intractable.

[choonge]

Thanks @DimitriPapadopoulos - created #365

[schlatterbeck]

Just for documentation: For me specifying the one-time token from my TOTP hardware token on the command-line with something like --otp number where number is (for my token) a 6-digit number still works fine for me with the latest version from git and without prompting me for a password.

So the question is: What sort of one-time password do you have? In my case it is generated by a hardware-token.

[mrbaseman]

I think we can close this one since for #365 there is a fix included in 1.7.1