Strange issue that hit me out of the blue: On Thursday, the Webmin login did work fine with my credentials and 2FA enabled. From Friday, after submitting my credentials, I receive a "Warning - Login Failed. Please try again.".
After two more failed attempts the message reads "403 - Access denied. The user has been blocked because of too many authentication failures." I then connected to my server via SSH and restarted Webmin to unblock my IP and tried again. Same result as above. I did these steps several times over the past days w/o any success.
The hosted websites and services do work fine. No issues occurred.
I did some research but couldn’t find something useful. There’s a thread here and another one there that suggests changing the theme (which didn’t work).
There are no errors in /var/webmin/miniserv.error – additionally, I unbanned all IPs from Fail2Ban and cross-checked for remainders:
fail2ban-client unban --all
iptables -n -L
In /etc/webmin/miniserv.users I can see the entry for my root user. Because the file was touched last end of August (and I definitely logged in successfully after), I decided not to mess with it.
I also deleted the entries in /var/webmin/blocked and stopped/started services individually, i. e. Webmin, Usermin, and rebooted the server itself. As the last straw I stopped the firewall and Fail2Ban.
None of the above actions turned out to be a success.
Neither did I change my login credentials nor run any critical upgrades or installed something new.
Any ideas what else I could try to log into Webmin again?
in /etc/webmin/miniserv.conf, remove twofactor_provider=totp
in /etc/webmin/miniserv.users, replace something like root:x:0:::::::0:0:totp:HBL7W4RTGXT6FG8W: with something like root:x:0:::::::0:0::HBL7W4RTGXT6FG8W:
restart Webmin with service webmin restart
See if you can login now with your old login and password, @Steini
That is resetting only the Webmin root password, and splits it off from the regular Linux password. If that’s what you want to do, that’s fine, but I recommend just setting the root (or your sudo user) password to one you know using the passwd command, rather than having multiple password databases.
I changed the root password via passwd several times after the incident occurred but still couldn’t log in. With the above hint it worked. Any idea why?
I updated the password handling underneath Webmin > Webmin Users > root > Webmin user access rights and set it back to “Unix authentication”. Works now but had to update the password once more via passwd. So far, all back in operation.
I’m assuming you had previously set the Webmin root password, and got yourself into the situation that I was recommending you avoid by only using one password source (the system shadow password file).
The default on installation is to use the system password. There are several ways to make that not true, both in the UI and via the command line. Using the changepass.pl script is one such way, but there are others.
I’m aware of many ways to eff up a server (have a vast array of experience in this field) but I defo didn’t change the password - neither through the UI nor the terminal. I’m glad it works again but am slightly worried about the how.
Valid concern. You could check the Webmin actions log to see if it was changed via the UI. I don’t believe any of the CLI methods would lead to action log entries, though. Of course, if someone had root-level access needed to change this, they also had root-level access needed to edit or delete the actions log.
I did because of the language translations where I switched back and forth between the default language and the translations. But I didn’t change the password setting during these procedures.
