Remove trust authentication from pg_hba.conf

The fixpg_hba.conf

# TYPE  DATABASE  USER  ADDRESS        METHOD
local   all       all                  peer
host    all       all   127.0.0.1/32   scram-sha-256
host    all       all   ::1/128        scram-sha-256

SELECT pg_reload_conf();

Why it matters

PostgreSQL’s documentation describes trust without euphemism:

This method allows anyone that can connect to the PostgreSQL database server to login as any PostgreSQL user they wish, without the need for a password or any other authentication.

Any user they wish includes postgres. There is no password to guess and no partial access to escalate from — reaching the socket is superuser. From there: read and write every database, COPY ... FROM PROGRAM to run shell commands as the postgres OS user, and read files off the host.

A trust line paired with a wide ADDRESS is the worst configuration in this cluster. It is also common, because it is what makes things work when authentication is misconfigured and someone is under time pressure.

Where trust comes from

Nobody sets this out of malice. It arrives three ways:

• Debugging. A connection fails, trust makes it succeed, and the change outlives the debugging session.
• Tutorials. A great deal of “getting started with Postgres” content sets trust for local connections to skip the password step.
• initdb --auth=trust, or an automation template that passes it.

The tell is that it always works. Nothing ever fails to remind you it’s there.

What to use instead

Connection	Use	Why
local (unix socket)	peer	Matches the OS user to the database user. No password to manage.
host loopback	scram-sha-256	A real password, hashed properly.
host remote	hostssl + scram-sha-256	See TLS — plain host permits unencrypted connections.

peer is the one people miss. For local socket connections it gives you the passwordless convenience that made trust attractive, while still being an actual authentication check — the kernel vouches for the OS user identity.

Verify it worked

Ask the server what it parsed rather than grepping the file. This covers include directives too:

SELECT type, database, user_name, address, auth_method
FROM pg_hba_file_rules
WHERE auth_method = 'trust';

An empty result is the goal. Any row is a live trust rule.

Check for parse errors while you are there:

SELECT line_number, error FROM pg_hba_file_rules WHERE error IS NOT NULL;

Then prove it — this should now demand a password:

psql -h 127.0.0.1 -U postgres -c 'SELECT 1'

If it connects with no prompt and no ~/.pgpass entry, a trust rule is still matching. Remember the first matching rule wins — a trust line above your scram line silently takes precedence, and nothing warns you.

Before you apply this

Removing trust breaks anything that relied on it — and those roles may have no password at all.

That’s the specific trap: roles created under trust often never had a password set, because none was needed. Switch to scram-sha-256 and they cannot authenticate by any means. Check before you reload:

SELECT rolname FROM pg_authid WHERE rolpassword IS NULL AND rolcanlogin;

Every role listed needs a password before the reload, or it is locked out:

ALTER ROLE myapp WITH PASSWORD 'generated-secret';

Sequence that avoids an outage:

1. Set passwords on all login roles while trust is still in place.
2. Confirm password_encryption is scram-sha-256 first — see scram, not md5 — or you will hash them with a deprecated algorithm and have to redo it.
3. Change the rules, check pg_hba_file_rules for errors, then reload.
4. Keep your existing session open until a fresh connection works.

A reload does not drop established connections, so an open psql is your way back in if the new rules are wrong.

Related

• Use scram-sha-256, not md5 — set this before you create passwords.
• Scope pg_hba.conf rules — trust plus a wide CIDR is the worst case.