How to Secure MariaDB on a VPS with mysql_secure_installation

MariaDB installs from Ubuntu's default repositories with a handful of settings that are fine for a quick local test and wrong for a database sitting on a public-facing VPS: an authentication setup that varies by version, sometimes an anonymous user that can connect without credentials, and a test database that anyone who can reach the server can read or drop. None of this is a bug; it is just what a database install looks like before someone runs the hardening step that MariaDB ships specifically for this purpose.

This guide runs mysql_secure_installation, MariaDB's official interactive hardening script, and explains what each prompt actually does so you are not just answering yes to questions you do not understand. It assumes you have a VPS with MariaDB already installed, for example from the [WordPress on Nginx and PHP-FPM deployment guide](/guides/deploy-wordpress-nginx-php-fpm), and a non-root sudo user.

Step 1 - Checking the Current Root Authentication Method

Before running the hardening script, confirm how the MariaDB root account currently authenticates, since this affects how you log in during the steps that follow. Connect as root:

sudo mysql -u root

Once connected, check the authentication plugin in use:

SELECT user, host, plugin FROM mysql.user WHERE user = 'root';

Output:

+------+-----------+-------------+
| user | host      | plugin      |
+------+-----------+-------------+
| root | localhost | unix_socket |
+------+-----------+-------------+

On a fresh Ubuntu install, root typically authenticates via unix_socket, meaning it only accepts connections from the Linux root or sudo user on the same machine rather than a password at all. This is worth knowing going in, since mysql_secure_installation will ask whether to set a root password and the correct answer depends on this. Exit the session before continuing:

EXIT;

Step 2 - Running mysql_secure_installation

With the current setup confirmed, run the hardening script itself. It walks through five decisions interactively rather than requiring you to write raw SQL for each one.

sudo mysql_secure_installation

The script starts by asking for the current root password. If root authenticates via unix_socket as confirmed in step 1, press Enter with no password rather than guessing at one; the script detects unix_socket auth and proceeds correctly.

Step 3 - Answering Each Prompt

Switch to unix_socket authentication or set a root password, when asked. If root is already using unix_socket, the script may offer to switch to a password instead; for a WordPress server where nothing but you connects as MariaDB root, staying on unix_socket is the stronger option since it removes password brute-forcing as an attack vector entirely for that account.

Remove anonymous users: answer yes. Anonymous MariaDB accounts exist by default in some installs specifically to let anyone connect without credentials for testing, and there is no reason to keep that open on a production server.

Disallow root login remotely: answer yes. WordPress and any application on this server should connect through a dedicated database user scoped to its own database, covered in step 4, never through the root account, and root has no legitimate reason to accept connections from outside localhost.

Remove the test database and access to it: answer yes. The test database ships with permissive access by default and is not used by WordPress or any real application; keeping it around is pure surface area with no upside.

Reload privilege tables now: answer yes. This applies every change made above immediately rather than waiting for the next MariaDB restart.

Step 4 - Creating a Dedicated Database User for WordPress

With root secured, WordPress still needs a database and a user scoped to only that database, never root. Connect again and create both:

sudo mysql

CREATE DATABASE wordpress_db;
CREATE USER 'wordpress_user'@'localhost' IDENTIFIED BY 'a-strong-unique-password';
GRANT ALL PRIVILEGES ON wordpress_db.* TO 'wordpress_user'@'localhost';
FLUSH PRIVILEGES;
EXIT;

This user can only read and write wordpress_db; it has no visibility into any other database that ends up on the same server later, which matters the moment you host a second site following the [guide to multiple WordPress sites on one VPS](/guides/multiple-wordpress-sites-vps-nginx-server-blocks). Use these credentials, not root, in wp-config.php.

Step 5 - Confirming the Hardening Took Effect

Verify the anonymous users and test database are actually gone rather than assuming the script applied cleanly. Connect as root again:

sudo mysql -u root -e "SELECT user, host FROM mysql.user; SHOW DATABASES;"

The user list should show only root and the wordpress_user created in step 4, with no blank username rows, and the database list should no longer include test. If either is still present, run mysql_secure_installation again; it is safe to run multiple times.

Your Database Is Now Hardened

MariaDB root no longer accepts remote or anonymous connections, the test database is gone, and WordPress connects through a dedicated user with access scoped to its own database only. From here, pairing this with the [automatic security updates guide](/guides/automatic-security-updates-ubuntu-unattended-upgrades) covers the other major gap on a self-managed database server: staying current with patches without having to remember to check for them.