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?
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"
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.
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.
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.