Frequent yubikey reauth required (client: v1.3.4099)

Pritunl Pritunl VPN
1

Pritunl client: v1.3.4099

My users are having to reauth with Yubikey frequently, despite using app.sso_client_cache_timeout = 604800.

The common scenario seems to be in the openvpn client. Prior to these reauth situations, we see this in the openvpn client logs:
2025-02-10 19:37:47 [662aa631872f5ffaa932624f] Peer Connection Initiated with [AF_INET]
2025-02-10 19:49:29 No reply from server to push requests in 702s
2025-02-10 19:49:29 SIGUSR1[soft,no-push-reply] received, process restarting
…
2025-02-10 19:49:32 [662aa631872f5ffaa932624f] Peer Connection Initiated with [AF_INET]
2025-02-10 19:49:33 AUTH: Received control message: AUTH_FAILED
2025-02-10 19:49:33 SIGTERM[soft,auth-failure] received, process exiting

There’s a long timeout and then the subsequent auth attempt always fails, likely leading to the pritunl client resetting the auth token.

Is there any way to avoid yubikey reauth in these situations?

2

Get the authentication error from the server logs in the top right of the web console.

3

I’m tracing a new instance, I see this. It appears the error is “Invalid sso token”.

client:

2025-02-24 18:00:25 [4bf4eca5b1ee1eacf65c3dbb0d6eaa79] Peer Connection Initiated with [AF_INET]69.122.180.83:1196
2025-02-24 18:15:47 No reply from server to push requests in 922s
2025-02-24 18:15:47 SIGUSR1[soft,no-push-reply] received, process restarting
.....
2025-02-24 18:15:48 TCP/UDP: Preserving recently used remote address: [AF_INET]69.122.180.83:1196
.....
2025-02-24 18:15:49 [4bf4eca5b1ee1eacf65c3dbb0d6eaa79] Peer Connection Initiated with [AF_INET]69.122.180.83:1196
2025-02-24 18:15:50 AUTH: Received control message: AUTH_FAILED

server:

[thawing-plains-2933] Tue Feb 25 02:00:25 2025 66.67.165.254:49364 [fbff2f0eabacc3c9ca2c64593f4eb1f5] Peer Connection Initiated with [AF_INET]66.67.165.254:49364
[thawing-plains-2933] 2025-02-25 02:00:26 COM> SUCCESS: client-auth command succeeded
[thawing-plains-2933] Tue Feb 25 02:00:26 2025 fbff2f0eabacc3c9ca2c64593f4eb1f5/66.67.165.254:49364 MULTI_sva: pool returned IPv4=192.168.192.2, IPv6=(Not enabled)
[thawing-plains-2933] 2025-02-25 02:00:26 User connected user_id=fbff2f0eabacc3c9ca2c64593f4eb1f5
[thawing-plains-2933] Tue Feb 25 02:01:46 2025 fbff2f0eabacc3c9ca2c64593f4eb1f5/66.67.165.254:49364 [fbff2f0eabacc3c9ca2c64593f4eb1f5] Inactivity timeout (--ping-restart), restarting
[thawing-plains-2933] 2025-02-25 02:01:46 User disconnected user_id=fbff2f0eabacc3c9ca2c64593f4eb1f5
[thawing-plains-2933] Tue Feb 25 02:15:49 2025 66.67.165.254:50245 peer info: IV_VER=2.6.12
[thawing-plains-2933] Tue Feb 25 02:15:49 2025 66.67.165.254:50245 peer info: IV_PLAT=mac
[thawing-plains-2933] 2025-02-25 02:15:49 COM> SUCCESS: client-deny command succeeded
[thawing-plains-2933] 2025-02-25 02:15:49 ERROR User auth failed "Invalid sso token"
4

The is the server output. Click logs in the top right of the web console on the navigation bar. What Single Sign-On set to in the top right settings? Then in the server settings check the values of Single Sign-On Authentication, Device Authentication and in the advanced section Dynamic Client Firewall.

5

Also when modifying app.sso_client_cache_timeout it requires running sudo systemctl restart pritunl after to update the database expire index. If you set that incorrectly in the past it may still have a very short expire index.

6

SSO: Google Apps + Yubico
Single Sign-On Authentication: Enabled
Device Authentication: Disabled
Dynamic Client Firewall: Disabled

This is all I see from System logs for my user. Nothing related follows that last log message:

[thawing-plains-2933][2025-02-25 02:00:23,425][INFO] Authenticating user
  user_name = "<user>"
  factors   = ["google", "yubico"]
[thawing-plains-2933][2025-02-25 02:00:23,430][INFO] Client authentication cached, skipping sso token
  user_name   = "<user>"
  org_name    = "engineering"
  server_name = "engineering"
[thawing-plains-2933][2025-02-25 02:00:23,430][INFO] Client authentication cached, skipping password
  user_name   = "<user>"
  org_name    = "engineering"
  server_name = "engineering"
[thawing-plains-2933][2025-02-25 02:00:25,120][INFO] Authenticating user
  user_name = "<user>"
  factors   = ["google", "yubico"]
[thawing-plains-2933][2025-02-25 02:00:25,121][INFO] Client authentication with sso token
  user_name   = "<user>"
  org_name    = "engineering"
  server_name = "engineering"
[thawing-plains-2933][2025-02-25 02:00:25,122][INFO] Client sso authentication, skipping password
  user_name   = "<user>"
  org_name    = "engineering"
  server_name = "engineering"
[thawing-plains-2933][2025-02-25 02:15:49,293][INFO] Authenticating user
  user_name = "<user>"
  factors   = ["google", "yubico"]
7

Thanks let me check this. Is there some way of knowing a restart is required (database expire index not updated)?

8

Check the indexes from the MongoDB shell use pritunl; db.sso_client_cache.getIndexes() to see what the current expiration is.

9

Is this what I should expect to see? Any thoughts on why we’re seeing the auth failures?

[
  { v: 2, key: { _id: 1 }, name: '_id_' },
  {
    v: 2,
    key: { user_id: 1, server_id: 1 },
    name: 'user_id_1_server_id_1',
    background: true
  },
  {
    v: 2,
    key: { timestamp: 1 },
    name: 'timestamp_1',
    background: true,
    expireAfterSeconds: 691200
  }
]
10

The logs indicate it’s working for at least most of the users. If it’s only some of the users there are things that will invalidate a token. The configuration sync may not be working which will cause the client to remove the token early. Click settings on the user profile and click debugging. Then verify the Token TTL is correct. The token is stored on in memory if the client system is restart it will remove the token.