Error pg hba conf

While connecting to PostgreSQL, users often notice the error “FATAL: no pg_hba.conf entry”.

As a part of our Server Management Service, we help our customers to fix PostgreSQL-related errors regularly.

Today, let us discuss the possible reasons and fixes for the error.

What is “FATAL: no pg_hba.conf entry” error

Connecting to PostgreSQL often triggers the error as shown below:

This error generally triggers due to incomplete entries in the pg_hba.conf file. Generally, this configuration file controls the client authentication and is stored in the database cluster’s data directory.

The general format of the pg_hba.conf file contains a set of records, one per line. A record contains a number of fields separated by spaces and/or tabs. Fields can contain white space, but we need to quote the field value.

Each record specifies a connection type, a client IP address range, a database name, a user name, and the authentication method for connections matching these parameters.

Further, 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.
 

How to fix “FATAL: no pg_hba.conf entry” error

1. Log in to Postgres SQL server with the use of ssh console.

2. Now, move to the data directory with the cd command.

cd /var/lib/pgsql/9.6/data/

3. Then, open pg_hba.conf file in an editor.

vi pg_hba.conf

4. Add an entry of the host IP address from which we try to connect. We can input the entry of the host to which we would like to provide access to:

# TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD
 
# IPv4 local connections:
host    all         all         127.0.0.1/32          md5
host    all  	    all  	xxx.xxx.xxx.xxx       md5
# IPv6 local connections:
host    all         all         ::1/128               md5

5. Then, restart the postgres SQL server.

systemctl restart postgresql-9.6.service

6. Try again in order to connect with the use of pgAdmin tool and we should be able to connect without any errors.

[Need help to fix PostgreSQL error? We are available 24*7]
 

Conclusion

In short, the “no pg_hba.conf entry” can happen due to missing entries in the configuration file. Today, we saw how our Support Engineers fix this error.

var google_conversion_label = «owonCMyG5nEQ0aD71QM»;

“FATAL: no pg_hba.conf entry” – How to fix the PostgreSQL error

by Arya MA | May 31, 2021

While connecting to PostgreSQL, users often notice the error “FATAL: no pg_hba.conf entry”.

As a part of our Server Management Service, we help our customers to fix PostgreSQL-related errors regularly.

Today, let us discuss the possible reasons and fixes for the error.

What is “FATAL: no pg_hba.conf entry” error

Connecting to PostgreSQL often triggers the error as shown below:

This error generally triggers due to incomplete entries in the pg_hba.conf file. Generally, this configuration file controls the client authentication and is stored in the database cluster’s data directory.

The general format of the pg_hba.conf file contains a set of records, one per line. A record contains a number of fields separated by spaces and/or tabs. Fields can contain white space, but we need to quote the field value.

Each record specifies a connection type, a client IP address range, a database name, a user name, and the authentication method for connections matching these parameters.

Further, 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.

How to fix “FATAL: no pg_hba.conf entry” error

1. Log in to Postgres SQL server with the use of ssh console.

2. Now, move to the data directory with the cd command.

3. Then, open pg_hba.conf file in an editor.

4. Add an entry of the host IP address from which we try to connect. We can input the entry of the host to which we would like to provide access to:

5. Then, restart the postgres SQL server.

6. Try again in order to connect with the use of pgAdmin tool and we should be able to connect without any errors.

[Need help to fix PostgreSQL error? We are available 24*7]

Conclusion

In short, the “no pg_hba.conf entry” can happen due to missing entries in the configuration file. Today, we saw how our Support Engineers fix this error.

PREVENT YOUR SERVER FROM CRASHING!

Never again lose customers to poor server speed! Let us help you.

Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.

Источник

connect to PostgreSQL server: FATAL: no pg_hba.conf entry for host

I am trying to run a website sent to me but after doing so this error appeared

connect to PostgreSQL server: FATAL: no pg_hba.conf entry for host «4X.XXX.XX.XXX», user «userXXX», database «dbXXX», SSL off in C:xampphtdocsxmastoolindex.php on line 37

I found this answer that says that I just need to add an entry in the pg_hba.conf file for that particular user.

This is my pg_hba.conf file.

but after doing so, the error still persists. I restarted my XAMPP server several times but nothing changes.

What do I need to change in pg_hba.conf ?

12 Answers 12

Add or edit the following line in your postgresql.conf :

Add the following line as the first line of pg_hba.conf . It allows access to all databases for all users with an encrypted password:

Restart Postgresql after adding this with service postgresql restart or the equivalent command for your setup. For brew, brew services restart postgresql

This solution works for IPv4 / IPv6:

Edit pga_hba.conf File

Open up the pga_hba.conf file in your favourite editor:

Append To pga_hba.conf File

Append the following lines to the end of the pga_hba.conf file:

Quit and save the editor of your preference.

Restart Service

Restart the postgresql service with the following command:

The way I solved this was:

Added the line as below in pg_hba.conf :

and this was modified in postgresql.conf , as shown:

I had this instance running on a Centos 7.3 and Postgres 9.5 in a VM in Azure, given this was a POC (proof of concept) you won’t want to connect without SSL in your actual prod environment.

To connect to the instance I was using pgAdmin 4 on macOS Sierra.

Fresh Postgres 9.5 install, Ubuntu.

The key was the local connection type, since psql uses domain socket connection.

Instructions for Debian users.

Login as posgres user:

Get the location of pg_hba.conf by quering the database:

Add configuration where it says «Put your actual configuration here»:

Logout to your user:

Restart your postgres server for changes to take effect:

Add the following line in the bottom of pg_hba.conf :

hostnossl all all 0.0.0.0/0 md5

Add/modify the line in postgresql.conf :

MAKE SURE THAT the user that is connecting has a password: (Example connect user named postgres )

a. Run the following psql command with the postgres user account:

sudo -u postgres psql postgres

b. Set the password:

This below worked for me: (pg_hba.conf)

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.

Require the client to supply a double-MD5-hashed password for authentication.

I had the same error when I tried to connect to a local database using an SSH tunnel. I solved it by changing the host name from localhost to 127.0.0.1 .

In my case I ran into this where I didn’t have access to edit any conf files on the server (.NET connecting to a managed db on DigitalOcean) so the other answers weren’t an option.

The host provided me a postgresql:// connection URL which had a ?sslmode= option on the end. I got the exact same error until I added «SSL Mode=Prefer;Trust Server Certificate=true;» to my translated .NET connectionString.

That may not be the optimal solution for me or for you, but I wanted to point out it’s possible that this is an issue with the connection string rather than the server config.

Источник

Resolve «FATAL:no pg_hba.conf entry for host» Error when you Connect from PGAdmin4

Available Languages

Download Options

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Contents

Introduction

This document describes how to resolve «FATAL: no pg_hba.conf entry for host» error when login to CloudCenter Manager Postgres standalone server with the use of PGAdmin tool.

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

Components Used

The information in this document is based on these software versions:

• CloudCenter version 4.8.2
• MGMTPOSTGRES_STANDALONE
• Posrgres9.6

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

Problem

When you try to connect the CloudCenter Postgres server with the use of pgAdmin, it fails with the «UNAUTHORIZED» error as shown in the image.

Solution

This authentication issue happens when you try to connect to the Postgres SQL server remotely other than the CloudCenter Manager server. In order to resolve this error, follow these steps:

1. Log in to Postgres SQL server with the use of ssh console.

2. cd to /var/lib/pgsql/9.6/data/.

3. Open pg_hba.conf file in an editor.

4. Add an entry of the host IP address from which you try to connect. You can input the entry of the host which you would like to provide access to as shown in the image.

5. Restart the postgres SQL server.

6. Try again in order to connect with the use of pgAdmin tool and you should be able to connect without any errors as shown in the image.

Источник

Server Error: No pg_hba.conf Entry for Host

In this entry, you will find resolutions for this error when attempting to connect remotely to a PostgreSQL database.

Date Entered: 3/18/2020 Last Updated: 3/18/2020 Author: Garrett Bird

When using one of the PostgreSQL connectors provided by CData, the error below is one of the common errors a user may face when connecting with a remote PostgreSQL database for the first time:

Server error: no pg_hba.conf entry for host «10.0.1.128», user «postgres», database «postgres», SSL off Connection was forcibly closed

This error can also occur if the user provides the actual IP address of a local PostgreSQL instance to the Server connection property, rather than «localhost.» In any case, the solution can be quickly resolved if the user can access the PostgreSQL instance itself, or can contact an administrator that manages it. The below steps will be all that is needed to enable remote connections to the server from your machine:

1. In the file explorer, navigate to «data» folder of your PostgreSQL installation. On Windows systems, the full path will generally be C:Program FilesPostgreSQL10data (The numbered folder can vary depending on the PostgreSQL version).
2. Within this directory will be a file called «pg_hba.conf.» Open this file in a text editor of your choice.
3. Once opened, simply add the below line toward the bottom of the file. In particular, it should be placed in the «IPv4 local connections» group (the IP address specified should be that of the machine you are connecting from): host all all 10.0.1.128/32 md5
4. Save and close the file with the change. Then, open the Services window on your machine.
5. In the list of currently running services, find the service for your PostgreSQL server and restart it. Doing so will apply the changes you made in the conf file to the PostgreSQL server.

Once the above steps are finished, you should now be able to remotely execute queries to your PostgreSQL server from your machine with any of the connectors provided by CData.

Источник

Error pg hba conf

Аутентификация клиентов управляется конфигурационным файлом, который традиционно называется pg_hba.conf и расположен в каталоге с данными кластера базы данных. (HBA расшифровывается как host-based authentication — аутентификации по имени узла.) Файл pg_hba.conf , со стандартным содержимым, создаётся командой initdb при инициализации каталога с данными. Однако его можно разместить в любом другом месте; см. конфигурационный параметр hba_file.

Общий формат файла pg_hba.conf — набор записей, по одной на строку. Пустые строки игнорируются, как и любой текст комментария после знака # . Запись может быть продолжена на следующей строке, для этого нужно завершить строку обратной косой чертой. (Обратная косая черта является спецсимволом только в конце строки.) Запись состоит из нескольких полей, разделённых пробелами и/или табуляциями. Поля могут содержать пробелы, если содержимое этих полей заключено в кавычки. Если в кавычки берётся какое-либо ключевое слово в поле базы данных, пользователя или адресации (например, all или replication ), то слово теряет своё особое значение и просто обозначает базу данных, пользователя или сервер с данным именем. Обратная косая черта обозначает перенос строки даже в тексте в кавычках или комментариях.

Каждая запись обозначает тип соединения, диапазон IP-адресов клиента (если он соотносится с типом соединения), имя базы данных, имя пользователя, и способ аутентификации, который будет использован для соединения в соответствии с этими параметрами. Первая запись с соответствующим типом соединения, адресом клиента, указанной базой данных и именем пользователя применяется для аутентификации. Процедур « fall-through » или « backup » не предусмотрено: если выбрана запись и аутентификация не прошла, последующие записи не рассматриваются. Если же ни одна из записей не подошла, в доступе будет отказано.

Записи могут иметь следующие форматы:

Значения полей описаны ниже:

Управляет подключениями через Unix-сокеты. Без подобной записи подключения через Unix-сокеты невозможны. host

Управляет подключениями, устанавливаемыми по TCP/IP. Записи host соответствуют подключениям c SSL и без SSL , а также подключениям, защищённым механизмами GSSAPI и не защищённым GSSAPI .

Примечание

Удалённое соединение по TCP/IP невозможно, если сервер запущен без определения соответствующих значений для параметра конфигурации listen_addresses, поскольку по умолчанию система принимает подключения по TCP/IP только для локального адреса замыкания localhost .

Управляет подключениями, устанавливаемыми по TCP/IP с применением шифрования SSL .

Чтобы использовать эту возможность, сервер должен быть собран с поддержкой SSL . Более того, механизм SSL должен быть включён параметром конфигурации ssl (подробнее об этом в Разделе 17.9). В противном случае запись hostssl не играет роли (не считая предупреждения о том, что ей не будут соответствовать никакие подключения). hostnossl

Этот тип записей противоположен hostssl , ему соответствуют только подключения по TCP/IP без шифрования SSL . hostgssenc

Управляет подключениями, устанавливаемыми по TCP/IP, для которых применяется шифрование GSSAPI .

Этот тип записей противоположен hostgssenc ; ему соответствуют только подключения по TCP/IP без шифрования GSSAPI . база

Определяет, каким именам баз данных соответствует эта запись. Значение all определяет, что подходят все базы данных. Значение sameuser определяет, что данная запись соответствует, только если имя запрашиваемой базы данных совпадает с именем запрашиваемого пользователя. Значение samerole определяет, что запрашиваемый пользователь должен быть членом роли с таким же именем, как и у запрашиваемой базы данных. ( samegroup — это устаревший, но допустимый вариант значения samerole .) Суперпользователи, несмотря на то, что они имеют полные права, считаются включёнными в samerole , только когда они явно входят в такую роль, непосредственно или косвенно. Значение replication показывает, что запись соответствует, когда запрашивается подключение для физической репликации, но не когда запрашивается подключение для логической. Имейте в виду, что для подключений физической репликации не указывается какая-то конкретная база данных, в то время как для подключений логической репликации должна указываться конкретная база. Любое другое значение воспринимается как имя определённой базы Postgres Pro . Несколько имён баз данных можно указать, разделяя их запятыми. Также можно задать отдельный файл с именами баз данных, написав имя файла после знака @ . пользователь

Указывает, какому имени (или именам) пользователя базы данных соответствует эта запись. Значение all указывает, что запись соответствует всем пользователям. Любое другое значение задаёт либо имя конкретного пользователя базы данных, либо имя группы (если это значение начинается с + ). (Напомним, что в Postgres Pro нет никакой разницы между пользователем и группой; знак + означает « совпадение любых ролей, которые прямо или косвенно являются членами роли » , тогда как имя без знака + является подходящим только для этой конкретной роли.) В связи с этим, суперпользователь рассматривается как член роли, только если он явно является членом этой роли, прямо или косвенно, а не только потому, что он является суперпользователем. Несколько имён пользователей можно указать, разделяя их запятыми. Файл, содержащий имена пользователей, можно указать, поставив знак @ в начале его имени. адрес

Указывает адрес (или адреса) клиентской машины, которым соответствует данная запись. Это поле может содержать или имя компьютера, или диапазон IP-адресов, или одно из нижеупомянутых ключевых слов.

Типичные примеры диапазонов адресов IPv4, указанных таким образом: 172.20.143.89/32 для одного компьютера, 172.20.143.0/24 для небольшой и 10.6.0.0/16 для крупной сети. Диапазон адресов IPv6 может выглядеть как ::1/128 для одного компьютера (это адрес замыкания IPv6) или как fe80::7a31:c1ff:0000:0000/96 для небольшой сети. 0.0.0.0/0 представляет все адреса IPv4, а ::0/0 — все адреса IPv6. Чтобы указать один компьютер, используйте длину маски 32 для IPv4 или 128 для IPv6. Опускать замыкающие нули в сетевом адресе нельзя.

Запись, сделанная в формате IPv4, подойдёт только для подключений по IPv4, а запись в формате IPv6 подойдёт только для подключений по IPv6, даже если представленный адрес находится в диапазоне IPv4-в-IPv6. Имейте в виду, что записи в формате IPv6 не будут приниматься, если системная библиотека С не поддерживает адреса IPv6.

Вы также можете прописать значение all , чтобы указать любой IP-адрес, samehost , чтобы указать любые IP-адреса данного сервера, или samenet , чтобы указать любой адрес любой подсети, к которой сервер подключён напрямую.

Если определено имя компьютера (всё, что не является диапазоном IP-адресов или специальным ключевым словом, воспринимается как имя компьютера), то оно сравнивается с результатом обратного преобразования IP-адреса клиента (например, обратного DNS-запроса, если используется DNS). При сравнении имён компьютеров регистр не учитывается. Если имена совпали, выполняется прямое преобразование имени (например, прямой DNS-запрос) для проверки, относится ли клиентский IP-адрес к адресам, соответствующим имени. Если двусторонняя проверка пройдена, запись считается соответствующей компьютеру. (В качестве имени узла в файле pg_hba.conf должно указываться то, что возвращается при преобразовании IP-адреса клиента в имя, иначе строка не будет соответствовать узлу. Некоторые базы данных имён позволяют связать с одним IP-адресом несколько имён узлов, но операционная система при попытке разрешить IP-адрес возвращает только одно имя.)

Указание имени, начинающееся с точки ( . ), соответствует суффиксу актуального имени узла. Так, .example.com будет соответствовать foo.example.com (а не только example.com ).

Когда в pg_hba.conf указываются имена узлов, следует добиться, чтобы разрешение имён выполнялось достаточно быстро. Для этого может быть полезен локальный кеш разрешения имён, например, nscd . Вы также можете включить конфигурационный параметр log_hostname , чтобы видеть в журналах имя компьютера клиента вместо IP-адреса.

Эти поля не применимы к записям local .

Примечание

Пользователи часто задаются вопросом, почему имена серверов обрабатываются таким сложным, на первый взгляд, способом, с разрешением двух имён, включая обратный запрос клиентского IP-адреса. Это усложняет процесс в случае, если обратная DNS-запись клиента не установлена или включает в себя нежелательное имя узла. Такой способ избран, в первую очередь, для повышения эффективности: в этом случае соединение требует максимум два запроса разрешения, один прямой и один обратный. Если есть проблема разрешения с каким-то адресом, то она остаётся проблемой этого клиента. Гипотетически, могла бы быть реализована возможность во время каждой попытки соединения выполнять только прямой запрос для разрешения каждого имени сервера, упомянутого в pg_hba.conf . Но если список имён велик, процесс был бы довольно медленным, а в случае наличия проблемы разрешения у одного имени сервера, это стало бы общей проблемой.

Также обратный запрос необходим для того, чтобы реализовать возможность соответствия суффиксов, поскольку для сопоставления с шаблоном требуется знать фактическое имя компьютера клиента.

Обратите внимание, что такое поведение согласуется с другими популярными реализациями контроля доступа на основе имён, такими как Apache HTTP Server и TCP Wrappers.

Эти два поля могут быть использованы как альтернатива записи IP-адрес / длина-маски . Вместо того, чтобы указывать длину маски, в отдельном столбце указывается сама маска. Например, 255.0.0.0 представляет собой маску CIDR для IPv4 длиной 8 бит, а 255.255.255.255 представляет маску CIDR длиной 32 бита.

Эти поля не применимы к записям local . метод-аутентификации

Указывает метод аутентификации, когда подключение соответствует этой записи. Варианты выбора приводятся ниже; подробности в Разделе 19.3. Все значения воспринимаются с учётом регистра и должны быть записаны в нижнем регистре, даже аббревиатуры типа ldap .

Разрешает безусловное подключение. Этот метод позволяет тому, кто может подключиться к серверу с базой данных Postgres Pro , войти под любым желаемым пользователем Postgres Pro без введения пароля и без какой-либо другой аутентификации. За подробностями обратитесь к Разделу 19.4. reject

Отклоняет подключение безусловно. Эта возможность полезна для « фильтрации » некоторых серверов группы, например, строка reject может отклонить попытку подключения одного компьютера, при этом следующая строка позволяет подключиться остальным компьютерам в той же сети. scram-sha-256

Проверяет пароль пользователя, производя аутентификацию SCRAM-SHA-256. За подробностями обратитесь к Разделу 19.5. md5

Проверяет пароль пользователя, производя аутентификацию SCRAM-SHA-256 или MD5. За подробностями обратитесь к Разделу 19.5. password

Требует для аутентификации введения клиентом незашифрованного пароля. Поскольку пароль посылается простым текстом через сеть, такой способ не стоит использовать, если сеть не вызывает доверия. За подробностями обратитесь к Разделу 19.5. gss

Для аутентификации пользователя использует GSSAPI. Этот способ доступен только для подключений по TCP/IP. За подробностями обратитесь к Разделу 19.6. Он может применяться в сочетании с шифрованием GSSAPI. sspi

Для аутентификации пользователя использует SSPI. Способ доступен только для Windows. За подробностями обратитесь к Разделу 19.7. ident

Получает имя пользователя операционной системы клиента, связываясь с сервером Ident, и проверяет, соответствует ли оно имени пользователя базы данных. Аутентификация ident может использоваться только для подключений по TCP/IP. Для локальных подключений применяется аутентификация peer. За подробностями обратитесь к Разделу 19.8. peer

Получает имя пользователя операционной системы клиента из операционной системы и проверяет, соответствует ли оно имени пользователя запрашиваемой базы данных. Доступно только для локальных подключений. За подробностями обратитесь к Разделу 19.9. ldap

Проводит аутентификацию, используя сервер LDAP . За подробностями обратитесь к Разделу 19.10. radius

Проводит аутентификацию, используя сервер RADIUS. За подробностями обратитесь к Разделу 19.11 cert

Проводит аутентификацию, используя клиентский сертификат SSL. За подробностями обратитесь к Разделу 19.12 pam

Проводит аутентификацию, используя службу подключаемых модулей аутентификации (PAM), предоставляемую операционной системой. За подробностями обратитесь к Разделу 19.13. bsd

Проводит аутентификацию, используя службу аутентификации BSD, предоставляемую операционной системой. За подробностями обратитесь к Разделу 19.14.

После поля метод-аутентификации может идти поле (поля) вида имя = значение , определяющее параметры метода аутентификации. Подробнее о параметрах, доступных для различных методов аутентификации, рассказывается ниже.

Помимо описанных далее параметров, относящихся к различным методам, есть один общий параметр аутентификации clientcert , который можно задать в любой записи hostssl . Он может принимать значения verify-ca и verify-full . В обоих случаях клиент должен предоставить годный (доверенный) сертификат SSL, но вариант verify-full дополнительно требует, чтобы значение cn (Common Name, Общее имя) в сертификате совпадало с именем пользователя или применимым сопоставлением. Это указание работает подобно методу аутентификации cert (см. Раздел 19.12), но позволяет связать проверку клиентских сертификатов с любым методом аутентификации, поддерживающим записи hostssl .

В любой записи, включающей аутентификацию по клиентскому сертификату (то есть в записи с методом аутентификации cert или с параметром clientcert ), в дополнительном параметре clientname можно выбрать сопоставляемый при проверке элемент учётных данных в клиентском сертификате. Этот параметр может иметь одно из двух значений. Если указано значение clientname=CN (оно подразумевается по умолчанию), имя пользователя сопоставляется с полем Common Name (CN) . Если указано значение clientname=DN — с полем Distinguished name (DN) . Этот вариант, вероятно, будет лучше использовать с сопоставлениями имён пользователей. Сравнение DN выполняется в формате RFC 2253. Извлечь поле DN в этом формате из клиентского сертификата можно так:

Использовать данный вариант следует с осторожностью, особенно когда для сопоставлений DN применяются регулярные выражения.

Источник

PROBLEM:

While connecting to a remote database with psql got below error.

-bash-4.2$hostname -i
192.168.2.3

-bash-4.2$ psql –host 192.268.8.0 -p 5444 -d postgres

psql: error: could not connect to server: FATAL: no pg_hba.conf entry for host “192.168.2.3”, user “enterprisedb”, database “postgres”, SSL off

SOLUTION:

In the above scenario, i was trying to connect to a database on remote host 192.268.8.0 from the local ip 192.168.2.3.

So we need to give authentication for the local ip inside pg_hba.conf file of remote server.

login to the remote server 192.268.8.0 and update the pg_hba.conf file:

pg_hba.conf can be found inside PGDATA directory.

vi pg_hba.conf

# "local" is for Unix domain socket connections only
local   all             all                                     peer
# IPv4 local connections:
host    all             all             127.0.0.1/32            ident
host    all             all             192.168.2.3/32          trust
# IPv6 local connections:

Now reload the config:

-bash-4.2$ psql -d postgres
psql (12.3.4)
Type "help" for help.

postgres=# SELECT pg_reload_conf()
;
 pg_reload_conf
----------------
 t
(1 row)

postgres=# select * from pg_hba_file_rules;
 line_number | type  |   database    | user_name |   address    |                 netmask                 | auth_method | options | error
-------------+-------+---------------+-----------+--------------+-----------------------------------------+-------------+---------+-------
          80 | local | {all}         | {all}     |              |                                         | peer        |         |
          82 | host  | {all}         | {all}     | 127.0.0.1    | 255.255.255.255                         | ident       |         |
          83 | host  | {all}         | {all}     | 192.168.2.3 | 255.255.255.255                         | trust       |         |
          85 | host  | {all}         | {all}     | ::1          | ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff | ident       |         |
          88 | local | {replication} | {all}     |              |                                         | peer        |         |
          89 | host  | {replication} | {all}     | 127.0.0.1    | 255.255.255.255                         | ident       |         |
          90 | host  | {replication} | {all}     | ::1          | ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff | ident       |         |
(7 rows)

Now test the connection :

-bash-4.2$  psql --host 192.268.8.0 -p 5444 -d postgres
psql (12.3.4)
Type "help" for help.

postgres=# conninfo
You are connected to database "postgres" as user "enterprisedb" on host "192.268.8.0" at port "5444".
postgres=#