After configuring bind addresses, we can move on to the next level. The pg_hba.conf file will tell PostgreSQL how to authenticate people coming over the network. In general, pg_hba.conf file entries have the following layout:

# local DATABASE USER METHOD [OPTIONS] 
# host DATABASE USER ADDRESS METHOD [OPTIONS] 
# hostssl DATABASE USER ADDRESS METHOD [OPTIONS] 
# hostnossl DATABASE USER ADDRESS METHOD [OPTIONS] 

There are four types of rules that can be put into the pg_hba.conf file:

• local: This can be used to configure local Unix socket connections.
• host: This can be used for SSL and non-SSL connections.
• hostssl: This is only valid for SSL connections. To make use of this option, SSL must be compiled into the server, which is the case if we are using prepackaged versions of PostgreSQL. In addition to that, ssl = on has to be set in the postgresql.conf file. This is the file when the server is started.
• hostnossl: This works for non-SSL connections.

A list of rules can be put into the pg_hba.conf file. Here is an example:

# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all trust

# IPv4 local connections:
host all all 127.0.0.1/32 trust

# IPv6 local connections:
host all all ::1/128 trust

You can see three simple rules. The local record says that all users from local Unix sockets for all databases are to be trusted. The trust method means that no password has to be sent to the server and people can log in directly. The other two rules say that the same applies to connections from localhost 127.0.0.1 and ::1/128, which is an IPv6 address.

As connecting without a password is certainly not the best choice for remote access, PostgreSQL provides various authentication methods that can be used to configure pg_hba.conf file flexibly. Here is the list of possible authentication methods:

• trust: This allows authentication without providing a password. The desired user has to be available on the PostgreSQL side.
• reject: The connection will be rejected.
• md5 and password: The connections can be created using a password. md5 means that the password is sent over the wire encrypted. In the case of passwords, the credentials are sent in plain text, which should not be done on a modern system anymore. md5 is not considered safe anymore. You should use scram-sha-256 instead in PostgreSQL 10 and beyond.
• scram-sha-256: This setting is the successor of md5 and uses a far more secure hash than the previous version.
• GSS and SSPI: This uses GSSAPI or SSPI authentication. This is only possible for TCP/IP connections. The idea here is to allow for single sign-on.
• ident: This obtains the operating system username of the client by contacting the ident server of the client and checking whether it matches the requested database username.
• peer: Suppose we are logged in as abc on Unix. If peer is enabled, we can only log in to PostgreSQL as abc. If we try to change the username, we will be rejected. The beauty is that abc won't need a password in order to authenticate. The idea here is that only the database administrator can log in to the database on a Unix system and not somebody else who just has the password or a Unix account on the same machine. This only works for local connections.
• PAM: This uses the pluggable authentication module (PAM). This is especially important if you want to use a means of authentication that is not provided by PostgreSQL out of the box. To use PAM, create a file called /etc/pam.d/postgresql on your Linux system and put the desired PAM modules you are planning to use into the config file. Using PAM, we can even authenticate against less common components. However, it can also be used to connect to Active Directory and so on.
• LDAP: This configuration allows you to authenticate using lightweight directory access protocol (LDAP). Note that PostgreSQL will only ask LDAP for authentication; if a user is present only on the LDAP but not on the PostgreSQL side, you cannot log in. Also note that PostgreSQL has to know where your LDAP server is. All of this information has to be stored in the pg_hba.conf file, as outlined in the official documentation: https://www.postgresql.org/docs/10/static/auth-methods.html#AUTH-LDAP.
• RADIUS: The remote authentication dial-in user service (RADIUS) is a means of performing single sign-on. Again, parameters are passed using configuration options.
• cert: This authentication method uses SSL client certificates to perform authentication, and therefore it is possible only if SSL is used. The advantage here is that no password has to be sent. The CN attribute of the certificate will be compared to the requested database username, and if they match, the login will be allowed. A map can be used to allow for user mapping.

Rules can simply be listed one after the other. The important thing here is that the order does make a difference, as shown in the following example:

host   all   all   192.168.1.0/24   scram-sha-256
host   all   all   192.168.1.54/32  reject

When PostgreSQL walks through the pg_hba.conf file, it will use the first rule that matches. So, if our request is coming from 192.168.1.54, the first rule will always match before we make it to the second one. This means that 192.168.1.54 will be able to log in if the password and user are correct; therefore, the second rule is pointless.

If we want to exclude the IP, make sure that those two rules are swapped.