Webmin default login and password reset

Webmin has no default login and no default password

Webmin ships no default username and password pair. There is nothing to look up, because the installer does not invent a credential: it authorises an account that already exists on the server, normally root, and tells Webmin to check that account's Unix password. So the login page is asking for a password you already control. If nobody ever set one, the login fails, and that is a missing password rather than a wrong one.

On a package install from the Webmin repository, the post-install step runs the setup with the login fixed to root. When /etc/shadow exists, which it does on every current Ubuntu and Debian system, it stores the password field as the literal letter x. That single letter is the marker for Unix authentication: it means "do not compare against anything stored here, ask the system instead". Webmin then validates the password through PAM (pluggable authentication modules) or the shadow file, exactly like su does.

This guide covers the three states people are actually in. You never had a Webmin password, you had one and forgot it, or your password is right but the server has stopped accepting logins from your address. The install itself is covered in the full Webmin setup guide for Ubuntu 24.04, so nothing below repeats it.

Which account did the install authorise?

Read the user file instead of guessing. Every Webmin login lives in /etc/webmin/miniserv.users, one per line, with the login name first and the password field second.

sudo cut -d: -f1,2 /etc/webmin/miniserv.users

A line such as root:x means the account root logs in with its Unix password. A line where the second field is a long hash means someone set a Webmin-only password for that account, and the Unix password is then ignored for Webmin. An empty second field means no password is accepted at all, which is a deliberate way to disable an account.

Paths move between distributions and between versions, so confirm yours before you act on anything here. The configuration directory is /etc/webmin on Ubuntu and Debian. The program directory is /usr/share/webmin on Ubuntu and Debian, and /usr/libexec/webmin on Enterprise Linux. ls /etc/webmin/miniserv.conf and ls /usr/share/webmin/bin/webmin tell you in one second which layout you have.

Case 1: you never set a Webmin password

This is the common one on a VPS. Cloud images of Ubuntu lock the root account, so /etc/shadow holds a placeholder that no password can ever match. Webmin authorised root, root has no usable password, and every attempt at the login page fails. Nothing is broken and nothing needs reinstalling.

You have two honest choices. Give root a Webmin-only password, which leaves the system account locked and is the safer option on a box where you normally log in as a sudo user:

sudo webmin passwd --user root --webmin-only

Or give root a real Unix password, which unlocks the account for the whole system, not only for Webmin. Do that only if you want that, and read what changing the VPS root password actually affects first, because it changes more than one login screen.

sudo webmin passwd --user root --unix

The webmin command is the command line interface (CLI) shipped with the package, and it refuses to run as an unprivileged user, so sudo is required. If your copy answers with an unknown-command error, it predates the CLI, which as of September 2026 has been in the package for several releases. Older installs use the bundled Perl script instead:

sudo /usr/share/webmin/changepass.pl /etc/webmin root NEW_PASSWORD_HERE

That script takes the configuration directory, the login name, and the new password, in that order. It sets a Webmin-only password, not the Unix one. Passing a password on the command line writes it into your shell history and exposes it in the process list while it runs, so prefer the interactive form and clear your history if you used the other.

Case 2: you set a Webmin password and forgot it

Run the same tool with no type flag and answer its question:

sudo webmin passwd --user root

When the login name also exists as a Unix account, the interactive run asks whether to change the Unix password or to set a separate Webmin-only one. That prompt is useful on its own, because it tells you which kind of password the account currently uses. Choosing the Unix option keeps one password for the server and for Webmin, so there is one thing to rotate. Choosing the Webmin-only option creates a second password that overrides Unix authentication for Webmin, which is what you want when the system account stays locked.

For a script or an automated rebuild, the non-interactive form exists:

sudo webmin passwd --user someuser --webmin-only --password NEW_PASSWORD_HERE

If the login you are fixing is not root but a sudo user, and that name is not in miniserv.users at all, then Webmin has no such user to give a password to. Log in as root first, open Webmin Users, create a user whose name matches the Unix account, choose Unix authentication, and grant it the modules it needs. Per-user module access is the main reason to run Webmin rather than a smaller panel, and it is one of the differences covered in the comparison of Cockpit and Webmin for server management.

Case 3: the login page stops accepting you after repeated failures

Webmin counts failed logins and then refuses the address, or the account, for a while. This is why a password that you have just fixed still does not work: the block is decided before the password is checked, so a correct password looks exactly like a wrong one. The counters and the durations live in /etc/webmin/miniserv.conf:

sudo grep -E '^(blockhost|blockuser|allow|deny)' /etc/webmin/miniserv.conf

blockhost_failures is how many failures block the client address, and blockhost_time is how many seconds that block lasts. blockuser_failures and blockuser_time do the same for the account name. Read the values on your own server rather than trusting a published default, because packages and panels ship different ones. A block expires on its own once its time has passed, so waiting is a valid fix and usually the fastest one.

Restarting the service clears the in-memory failure counters, which is the quickest way to get back in if the timeout is long:

sudo webmin server restart
sudo webmin server status

Check the system log before you assume it was a typo of your own. Webmin reports a block at critical level with the phrase Security alert, naming the address, the account, and the number of failures:

sudo journalctl --since -1h | grep 'Security alert'

Repeated blocks from addresses you do not recognise mean the login page is being attacked from the open internet, which is the real problem to solve, not the block. Also read the allow= and deny= lines from the same grep. Those are a permanent address restriction, not a temporary block. If allow= is set and your current address is not in it, you are refused before any password is read, and no amount of password resetting will change that.

Two-factor and the failures that are not password failures

If the account has two-factor authentication enrolled and you lost the device, the password alone will never be enough. Remove the enrolment from the shell, then log in and enrol again:

sudo webmin disable-twofactor --user root

Three more things look like a rejected password and are not. The service may be stopped, so sudo webmin server status and sudo ss -lntp | grep 10000 tell you whether anything is listening on port 10000. The scheme may be wrong: a default install serves HTTPS, and browsing to http:// on the same port returns a protocol error rather than a login form. Or the port may be closed upstream, on the VPS firewall or on your provider's separate network firewall, which you can check against the active firewall rules on the server. Webmin's own logs sit in /var/webmin/miniserv.log for requests and /var/webmin/miniserv.error for startup problems, and the error log is where a configuration file it refused to parse will be named.

Stop exposing the login page at all

A login page on port 10000 with a password on it is a permanent target, and every password-reset visit you make to this page is one more reason to take it off the public internet. Bind the service to the loopback address by setting bind=127.0.0.1 in /etc/webmin/miniserv.conf, then restart it with sudo webmin server restart. Webmin now answers only from the server itself. Reach it through an SSH (secure shell) tunnel from your own machine:

ssh -N -L 10000:127.0.0.1:10000 you@your.server

Leave that running and open https://127.0.0.1:10000 in your browser. The certificate warning is expected, because a fresh install generates its own certificate, and how self-signed certificates work on Ubuntu explains what the browser is objecting to. With the tunnel in place, the only public door left is SSH itself, so harden that one properly using key-only SSH access and the rest of the hardening checklist.

If you must keep Webmin reachable, add fail2ban so the blocking survives a restart and covers the whole server rather than one service. Webmin writes failed logins to the authentication log through syslog, and fail2ban ships a matching filter already:

sudo apt install -y fail2ban

[webmin-auth]
enabled = true
port = 10000

Put that in /etc/fail2ban/jail.local, restart fail2ban, then confirm the jail is live and watching a log file that exists:

sudo systemctl restart fail2ban
sudo fail2ban-client status webmin-auth

A healthy result lists the file being monitored and a count of currently banned addresses. If the file list is empty or the jail is missing, the filter found no log to read, which usually means Webmin is not logging to syslog on that box. When fail2ban bans you by mistake, lift it by address:

sudo fail2ban-client set webmin-auth unbanip 203.0.113.9

FAQ

What is the default username and password for Webmin?

There is not one. Webmin does not create a credential pair at install time. A package install authorises the existing root account and stores x as its password field in /etc/webmin/miniserv.users, which means Webmin validates the password against the system, through PAM or the shadow file. So the correct login on a fresh install is root plus root's Unix password. On a cloud VPS image where root is locked, that password does not exist yet, which is why the login fails with no wrong password involved.

How do I reset the Webmin root password from the command line?

As root, run webmin passwd --user root. Interactive mode asks whether to change the Unix password or set a separate Webmin-only password. Use --unix to keep one password for the whole server, or --webmin-only to leave the system account untouched. Packages older than the webmin CLI use the bundled script instead, changepass.pl <config-dir> <login> <password>, which lives in /usr/share/webmin on Ubuntu and Debian and in /usr/libexec/webmin on Enterprise Linux. Confirm which of those directories exists before running it.

Why does Webmin refuse my login after several wrong tries?

Webmin counts failures and blocks the client address or the account for a set time, and the block is checked before the password is, so a correct password is rejected the same way a wrong one is. The counters are blockhost_failures with blockhost_time, and blockuser_failures with blockuser_time, all in /etc/webmin/miniserv.conf. The block expires by itself once the time passes. Restarting the service with webmin server restart clears the counters immediately. Search the system log for Security alert to confirm that is what happened.

Can I log in to Webmin with a sudo user instead of root?

Yes, but the account has to exist inside Webmin first. Having sudo on the server does not create a Webmin user by itself. Log in as root, open Webmin Users, add a user whose name matches the Unix account, pick Unix authentication so it uses that account's normal password, and grant only the modules that person needs. Doing this per person is better than sharing the root login, because the action log then names who did what.