Client authentication is controlled by a configuration file,
which traditionally is named pg_hba.conf and is stored in the database
cluster's data directory. (HBA
stands for host-based authentication.) A default pg_hba.conf file is installed when the data
directory is initialized by initdb. It
is possible to place the authentication configuration file
elsewhere, however; see the hba_file
configuration parameter.

The general format of the pg_hba.conf file is a set of records, one per
line. Blank lines are ignored, as is any text after the
# comment character. Records cannot be
continued across lines. A record is made up of a number of fields
which are separated by spaces and/or tabs. Fields can contain
white space if the field value is quoted. Quoting one of the
keywords in a database or user name field (e.g., all or replication) makes
the word lose its special character, and just match a database or
user with that name.

Each record specifies a connection type, a client IP address
range (if relevant for the connection type), a database name, a
user name, and the authentication method to be used for
connections matching these parameters. The first record with a
matching connection type, client address, requested database, and
user name is used to perform authentication. There is no
"fall-through" or "backup": if one record is chosen and the
authentication fails, subsequent records are not considered. If
no record matches, access is denied.

This record matches connection attempts using
Unix-domain sockets. Without a record of this type,
Unix-domain socket connections are disallowed.

host

This record matches connection attempts made using
TCP/IP. host records match either
SSL or
non-SSL connection
attempts.

Note: Remote TCP/IP connections will not be
possible unless the server is started with an
appropriate value for the listen_addresses
configuration parameter, since the default behavior is
to listen for TCP/IP connections only on the local
loopback address localhost.

hostssl

This record matches connection attempts made using
TCP/IP, but only when the connection is made with
SSL encryption.

To make use of this option the server must be built with
SSL support.
Furthermore, SSL must be
enabled at server start time by setting the ssl
configuration parameter (see Section
17.8 for more information).

hostnossl

This record type has the opposite behavior of hostssl; it only matches connection attempts
made over TCP/IP that do not use SSL.

database

Specifies which database name(s) this record matches.
The value all specifies that it
matches all databases. The value sameuser specifies that the record matches
if the requested database has the same name as the
requested user. The value samerole
specifies that the requested user must be a member of the
role with the same name as the requested database.
(samegroup is an obsolete but
still accepted spelling of samerole.) The value replication specifies that the record
matches if a replication connection is requested (note that
replication connections do not specify any particular
database). Otherwise, this is the name of a specific
PostgreSQL database.
Multiple database names can be supplied by separating them
with commas. A separate file containing database names can
be specified by preceding the file name with @.

user

Specifies which database user name(s) this record
matches. The value all specifies
that it matches all users. Otherwise, this is either the
name of a specific database user, or a group name preceded
by +. (Recall that there is no
real distinction between users and groups in PostgreSQL; a + mark really means "match any of the roles that are directly or
indirectly members of this role", while a name
without a + mark matches only that
specific role.) Multiple user names can be supplied by
separating them with commas. A separate file containing
user names can be specified by preceding the file name with
@.

CIDR-address

Specifies the client machine IP address range that this
record matches. This field contains an IP address in
standard dotted decimal notation and a CIDR mask length. (IP addresses can
only be specified numerically, not as domain or host
names.) The mask length indicates the number of high-order
bits of the client IP address that must match. Bits to the
right of this must be zero in the given IP address. There
must not be any white space between the IP address, the
/, and the CIDR mask length.

Instead of a CIDR-address, you can write
samehost to match any of the
server's own IP addresses, or samenet to match any address in any subnet
that the server is directly connected to.

Typical examples of a CIDR-address are 172.20.143.89/32 for a single host, or
172.20.143.0/24 for a small
network, or 10.6.0.0/16 for a
larger one. 0.0.0.0/0
("all balls") represents all
addresses. To specify a single host, use a CIDR mask of 32
for IPv4 or 128 for IPv6. In a network address, do not omit
trailing zeroes.

An entry given in IPv4 format will match only IPv4
connections, and an entry given in IPv6 format will match
only IPv6 connections, even if the represented address is
in the IPv4-in-IPv6 range. Note that entries in IPv6 format
will be rejected if the system's C library does not have
support for IPv6 addresses.

This field only applies to host, hostssl, and
hostnossl records.

IP-addressIP-mask

These fields can be used as an alternative to the
CIDR-address notation.
Instead of specifying the mask length, the actual mask is
specified in a separate column. For example, 255.0.0.0 represents an IPv4 CIDR mask
length of 8, and 255.255.255.255
represents a CIDR mask length of 32.

These fields only apply to host, hostssl, and
hostnossl records.

auth-method

Specifies the authentication method to use when a
connection matches this record. The possible choices are
summarized here; details are in Section 19.3.

trust

Allow the connection unconditionally. 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. See Section 19.3.1 for
details.

reject

Reject the connection unconditionally. This is
useful for "filtering out"
certain hosts from a group, for example a reject line could block a specific
host from connecting, while a later line allows the
remaining hosts in a specific network to connect.

md5

Require the client to supply an MD5-encrypted
password for authentication. See Section 19.3.2
for details.

password

Require the client to supply an unencrypted
password for authentication. Since the password is
sent in clear text over the network, this should not
be used on untrusted networks. See Section 19.3.2
for details.

gss

Use GSSAPI to authenticate the user. This is only
available for TCP/IP connections. See Section 19.3.3
for details.

sspi

Use SSPI to authenticate the user. This is only
available on Windows. See Section 19.3.4 for
details.

krb5

Use Kerberos V5 to authenticate the user. This is
only available for TCP/IP connections. See Section 19.3.5
for details.

ident

Obtain the operating system user name of the
client (for TCP/IP connections by contacting the
ident server on the client, for local connections by
getting it from the operating system) and check if it
matches the requested database user name. See
Section
19.3.6 for details.

Authenticate using SSL client certificates. See
Section
19.3.9 for details.

pam

Authenticate using the Pluggable Authentication
Modules (PAM) service provided by the operating
system. See Section 19.3.10 for
details.

auth-options

After the auth-method
field, there can be field(s) of the form name=value that
specify options for the authentication method. Details
about which options are available for which authentication
methods appear below.

Files included by @ constructs are
read as lists of names, which can be separated by either
whitespace or commas. Comments are introduced by #, just as in pg_hba.conf, and nested @ constructs are allowed. Unless the file name
following @ is an absolute path, it is
taken to be relative to the directory containing the referencing
file.

Since the pg_hba.conf records are
examined sequentially for each connection attempt, the order of
the records is significant. Typically, earlier records will have
tight connection match parameters and weaker authentication
methods, while later records will have looser match parameters
and stronger authentication methods. For example, one might wish
to use trust authentication for local
TCP/IP connections but require a password for remote TCP/IP
connections. In this case a record specifying trust authentication for connections from
127.0.0.1 would appear before a record specifying password
authentication for a wider range of allowed client IP
addresses.

The pg_hba.conf file is read on
start-up and when the main server process receives a SIGHUP signal. If you edit the file on an
active system, you will need to signal the postmaster (using
pg_ctl reload or kill -HUP) to make it re-read the file.

Tip: To connect to a particular database, a user
must not only pass the pg_hba.conf
checks, but must have the CONNECT
privilege for the database. If you wish to restrict which
users can connect to which databases, it's usually easier to
control this by granting/revoking CONNECT privilege than to put the rules in
pg_hba.conf entries.

Some examples of pg_hba.conf entries
are shown in Example 19-1. See
the next section for details on the different authentication
methods.

Example 19-1. Example pg_hba.conf entries

# Allow any user on the local system to connect to any database with
# any database user name using Unix-domain sockets (the default for local
# connections).
#
# TYPE DATABASE USER CIDR-ADDRESS METHOD
local all all trust
# The same using local loopback TCP/IP connections.
#
# TYPE DATABASE USER CIDR-ADDRESS METHOD
host all all 127.0.0.1/32 trust
# The same as the previous line, but using a separate netmask column
#
# TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD
host all all 127.0.0.1 255.255.255.255 trust
# Allow any user from any host with IP address 192.168.93.x to connect
# to database "postgres" as the same user name that ident reports for
# the connection (typically the operating system user name).
#
# TYPE DATABASE USER CIDR-ADDRESS METHOD
host postgres all 192.168.93.0/24 ident
# Allow any user from host 192.168.12.10 to connect to database
# "postgres" if the user's password is correctly supplied.
#
# TYPE DATABASE USER CIDR-ADDRESS METHOD
host postgres all 192.168.12.10/32 md5
# In the absence of preceding "host" lines, these two lines will
# reject all connections from 192.168.54.1 (since that entry will be
# matched first), but allow Kerberos 5 connections from anywhere else
# on the Internet. The zero mask causes no bits of the host IP
# address to be considered, so it matches any host.
#
# TYPE DATABASE USER CIDR-ADDRESS METHOD
host all all 192.168.54.1/32 reject
host all all 0.0.0.0/0 krb5
# Allow users from 192.168.x.x hosts to connect to any database, if
# they pass the ident check. If, for example, ident says the user is
# "bryanh" and he requests to connect as PostgreSQL user "guest1", the
# connection is allowed if there is an entry in pg_ident.conf for map
# "omicron" that says "bryanh" is allowed to connect as "guest1".
#
# TYPE DATABASE USER CIDR-ADDRESS METHOD
host all all 192.168.0.0/16 ident map=omicron
# If these are the only three lines for local connections, they will
# allow local users to connect only to their own databases (databases
# with the same name as their database user name) except for administrators
# and members of role "support", who can connect to all databases. The file
# $PGDATA/admins contains a list of names of administrators. Passwords
# are required in all cases.
#
# TYPE DATABASE USER CIDR-ADDRESS METHOD
local sameuser all md5
local all @admins md5
local all +support md5
# The last two lines above can be combined into a single line:
local all @admins,+support md5
# The database column can also use lists and file names:
local db1,db2,@demodbs all md5