Can't login to webgui when totp is enabled

me.mr

New Member
Dec 18, 2023
8
0
1
Hello everyone recently, after upgrading to pve 9, I can no longer use totp and log in to the web gui. When logging in after entering password I get a 401 error. After disabling totp via ssh I can login normally.

I would appreciate any help!
 
Hi,

Have you check you had the latest version, it's been fixed with last updates.

Best regards,
 
I continue to have this issue with the latest updates (on enterprise).

Edit:
Adding on to this, I am able to pass the challenge to add a TOTP, but once it is added, the user is unable to login through the webgui until it is removed.

Login failed:
authentication failure (401)
Please try again
 
Last edited:
I have the same issue here, however, I'm able to access it via SSH, and if I remove the TOTP config for my user using CLI, it works.
Is there a bug, is somebody working on it ?
 
I have no idea what the current problem is, but I want to post a generic reminder for basic knowledge: the most fundamental problem with TOTP is that the clocks may drift apart. Only a few seconds are acceptable; the interval between renewals is 30 seconds (usually).
 
  • Like
Reactions: Johannes S
I have no idea what the current problem is, but I want to post a generic reminder for basic knowledge: the most fundamental problem with TOTP is that the clocks may drift apart. Only a few seconds are acceptable; the interval between renewals is 30 seconds (usually).
Thank you for this and it is very good knowledge to have. In my situation I am able to add the TOTP as an option, which means I am answering back the challenge code correctly, which I think rules out the system clock being an issue.
 
  • Like
Reactions: Johannes S and UdoB
I can confirm 2FA seems broken (atleast for me, too). The TOTP popup never shows when atleast one account has TOTP enabled. When removing the user from the /etc/pve/priv/tfa.cfg, or the file itself, the user can log back in. When re-enabling TOTP the problem persists.

  1. The system is fully up to date, there are no updates available.
  2. I've disabled Bitwarden for Firefox although I've never experienced the bug mentioned.
  3. I've used Chrome to check if this is a Firefox issue, I get the same "Login failure, authentication failure (401) Please try again"
  4. It doesn't matter which realm I use,
  5. I did a "apt install --reinstall pve-manager proxmox-widget-toolkit libjs-extjs" just to be sure (this machine has no subscription) and restarted pve-proxy.
  6. I connect to this machine directly on its IP using port 8006.
  7. When I check "timedatectl status" it says it's working perfectly and I can confirm this, the time is synced correctly to the second.
So I dug a little deeper, when I use "journalctl -f" to catch something happening while using TOTP through Chrome I get "rp_id is not an effective_domain of rp_origin".

full log:

Aug 27 11:21:27 pve1 perl[13946]: rp_id is not an effective_domain of rp_origin
Aug 27 11:21:27 pve1 pvedaemon[13946]: authentication failure; rhost=::ffff:10.0.0.91 user=root@pam msg=failed to begin webauthn context instantiation: The configuration was invalid
Aug 27 11:21:48 pve1 perl[13945]: rp_id is not an effective_domain of rp_origin
Aug 27 11:21:48 pve1 pvedaemon[13945]: authentication failure; rhost=::ffff:10.0.0.91 user=root@pam msg=failed to begin webauthn context instantiation: The configuration was invalid
Aug 27 11:22:05 pve1 perl[13947]: rp_id is not an effective_domain of rp_origin
Aug 27 11:22:05 pve1 pvedaemon[13947]: authentication failure; rhost=::ffff:10.0.0.91 user=root@pam msg=failed to begin webauthn context instantiation: The configuration was invalid

It seems related to webauth, which I dont use but somehow the code still seems to get triggered so, in that case this would definitly be a bug. webauth should not be triggered when it's not being used.
 
Ok so a (in my case) workaround:

- in datacenter -> options -> webauth settings, added a FQDN which I made up on the spot
- on my Linux hosts in /etc/hosts I added 10.0.0.240 and after that the made up FQDN (like "10.0.0.240 meteor.sol.com")
- on my only windows host under windows\system32\drivers\etc\hosts did the same

and now it works again (when visiting meteor.sol.com, not the IP).

It's strange that on version 8 this didn't seem to matter.
 
Last edited: