Методы аутентификации

QHB предоставляет к использованию разнообразные методы аутентификации пользователей:

Для локальных подключений обычно рекомендуется аутентификация peer, хотя в некоторых обстоятельствах может быть достаточно и аутентификации trust. Для удаленных подключений самой простой будет аутентификация по паролю. Все прочие варианты требуют участия некоторой внешней инфраструктуры безопасности (обычно это сервер аутентификации или центр сертификации, выдающий сертификаты SSL) или поддерживаются не на всех платформах.

Аутентификация trust

Когда указан метода аутентификации trust, QHB предполагает, что любой подключающийся к серверу авторизован для доступа к базе данных, независимо от указанного имени пользователя базы данных (даже если это имя суперпользователя). Разумеется, ограничения, прописанные в столбцах database и user, продолжают действовать. Этот метод следует применять только в том случае, когда на уровне операционной системы обеспечена адекватная защита подключений к серверу.

Аутентификация trust оптимальна и очень удобна для локальных подключений на однопользовательской рабочей станции. Обычно само по себе этот метод не подходит для машин с несколькими пользователями. Однако его можно использовать даже на многопользовательской машине, если ограничить доступ к серверному файлу сокета домена Unix посредством разрешений файловой системы. Для этого нужно установить параметры конфигурации unix_socket_permissions (и, возможно, unix_socket_group) как описано в подразделе Подключения и аутентификация. Или можно установить параметр конфигурации unix_socket_directories, чтобы разместить файл сокета в должным образом защищенном каталоге.

Установка разрешений на уровне файловой системы помогает только в случае подключения через сокеты Unix. На локальные подключения по TCP/IP ограничения файловой системы не действуют. Таким образом, если вы хотите использовать разрешения файловой системы для обеспечения локальной безопасности, уберите строку host ... 127.0.0.1 ... из файла pg_hba.conf или смените метод аутентификации.

Аутентификация trust подойдет для подключений по TCP/IP, только если вы доверяете каждому пользователю на каждом компьютере, который получил разрешение на подключение к серверу строками файла pg_hba.conf, указывающими метод trust. Не рекомендуется использовать trust для любых подключений по TCP/IP, отличных от localhost (127.0.0.1).

Аутентификация по паролю

Существует несколько методов аутентификации по паролю. Эти методы работают сходным образом, но различаются тем, как пароли пользователей хранятся на сервере и как предоставленный клиентом пароль передается через соединение.

scram-sha-256

С методом scram-sha-256 выполняется аутентификация SCRAM-SHA-256, как описано в RFC 7677. Она производится по схеме запрос-ответ, предотвращающей перехват паролей через недоверенные соединения и поддерживающей хранение паролей на сервере в криптографически хешированной форме, которая считается безопасной.

Это наиболее безопасный из предоставляемых на данный момент методов, но он не поддерживается старыми клиентскими библиотеками.

md5

В методе md5 применяется нестандартный и менее безопасный механизм запрос- ответ. Он предотвращает перехват паролей и не допускает хранение паролей на сервере в виде простого текста, но не обеспечивает защиту, если злоумышленнику удается похитить хеши паролей с сервера. Кроме того, в наши дни алгоритм хеширования MD5 уже не считается способным защитить от целенаправленных атак.

Метод md5 несовместим с функциональностью db_user_namespace.

Для облегчения перехода от метода md5 к более новому методу SCRAM, если в качестве метода аутентификации в файле pg_hba.conf указан md5, но пароль пользователя на сервере зашифрован для SCRAM (см. ниже), то будет автоматически выполняться аутентификация на основе SCRAM.

password

С методом password пароль передается открытым текстом и поэтому является уязвимым для атак с перехватом паролей. По возможности его всегда следует избегать. Однако если подключение защищено шифрованием SSL, то метод password может быть безопасен. (Хотя при использовании SSL, возможно, лучшим выбором будет аутентификация по сертификату SSL.)

Пароли баз данных QHB отделены от паролей пользователей операционной системы. Пароли всех пользователей базы данных хранятся в системном каталоге pg_authid. Управлять паролями можно либо с помощью команд SQL CREATE ROLE и ALTER ROLE, например, CREATE ROLE foo WITH LOGIN PASSWORD 'secret', либо с помощью команды psql \password. Если пароль для пользователя не задан, вместо него хранится NULL, и пройти аутентификацию по паролю этот пользователь не сможет.

Доступность различных методов аутентификации по паролю зависит от того, как пароли пользователей шифруются на сервере (или, если точнее, хешируются). Это определяется параметром конфигурации password_encryption в момент назначения пароля. Если пароль шифруется алгоритмом scram-sha-256, его можно будет использовать для методов аутентификации scram-sha-256 и password (но в последнем случае пароль будет передаваться открытым текстом). При этом в случае указания метода аутентификации md5 произойдет автоматическое переключение на использование метода scram-sha-256, как описано выше, так что этот вариант тоже будет работать. Если пароль шифруется алгоритмом md5, то его можно будет использовать только для методов аутентификации md5 и password (опять же, в последнем случае пароль будет передаваться открытым текстом). Чтобы проверить хранящиеся в данный момент в базе данных хеши паролей, обратитесь к системному каталогу pg_authid.

Чтобы перевести существующую инсталляцию с md5 на scram-sha-256, сперва убедитесь о том, что все клиентские библиотеки были обновлены до версий, поддерживающих SCRAM, задайте password_encryption = 'scram-sha-256' в qhb.conf, заставьте всех пользователей сменить свои пароли, а затем поменяйте указание метода аутентификации в pg_hba.conf на scram-sha-256.

Аутентификация GSSAPI

GSSAPI — это принятый в качестве отраслевого стандарта протокол для безопасной аутентификации, определенный в RFC 2743. QHB поддерживает применение GSSAPI для аутентификации, шифрования соединений, а также для аутентификации с шифрованием. GSSAPI предоставляет автоматическую аутентификацию (система единого входа) для систем, которые ее поддерживают. Сама по себе аутентификация безопасна, но данные, передаваемые через подключение к базе данных, будут кодироваться, только если используется шифрование GSSAPI или SSL.

Поддержку GSSAPI следует включать при сборке QHB; дополнительную информацию см. в главе Установка.

При работе с Kerberos GSSAPI использует стандартные имена субъектов-служб (аутентификационные идентификаторы) в формате имя_службы/ имя_хоста@область. Имя субъекта-службы, используемое конкретной инсталляцией, не закодировано в сервере QHB ни в каком виде; оно задается в файле keytab, который сервер прочитывает для определения его идентификатора. Если в файле keytab перечислено несколько субъектов-служб, сервер выберет любой из них. В качестве области сервера задается предпочитаемая область, указанная в доступном серверу файле (или файлах) конфигурации Kerberos.

Клиент должен знать имя субъекта-службы сервера, к которому он намерен подключиться. Обычно в качестве элемента имя_службы субъекта службы указывается qhb, но в параметре подключения krbsrvname в libpq можно выбрать и другое значение. В элементе имя_хоста задается полное имя узла, к которому будет подключаться libpq. В элементе область задается предпочитаемая область, указанная в доступном клиенту файле (или файлах) конфигурации Kerberos.

У клиента также должно быть имя субъекта-службы для его собственного идентификатора (и он должен иметь действительный билет для этого субъекта- службы). Чтобы использовать GSSAPI для аутентификации, субъект-службы клиента должен быть связан с именем пользователя базы данных QHB. Для сопоставления имен субъектов-служб с именами пользователей можно воспользоваться файлом конфигурации pg_ident.conf; например, pgusername@realm можно сопоставить с простым pgusername. Как вариант, можно использовать полное имя субъекта-службы username@realm в качестве имени роли в QHB без какого-либо сопоставления.

QHB также поддерживает сопоставление субъектов-служб клиентов с именами пользователей путем простого удаления элемента области из имени субъекта- службы. Этот метод оставлен для обратной совместимости и настоятельно не рекомендуется к использованию, поскольку при этом невозможно различить разных пользователей с одинаковыми именами, но приходящих из разных областей. Чтобы включить этот режим, установите для include_realm значение 0. В простых инсталляциях с одной областью исключение области в сочетании с установкой параметра krb_realm (который позволяет ограничить область субъекта-службы значением, заданным в параметре krb_realm) все же будет безопасным, но менее эффективным подходом по сравнению с явным сопоставлением в pg_ident.conf.

Расположение файла keytab на сервере задается параметром конфигурации krb_server_keyfile. По соображениям безопасности рекомендуется использовать отдельный файл keytab специально для сервера QHB, а не разрешать серверу читать системный файл keytab. Сделайте так, чтобы пользователь, от имени которого запущен сервер QHB, имел право на чтение этого серверного файла keytab (право на запись давать не стоит). (См. также раздел Учетная запись пользователя.)

Файл keytab генерируется с использованием ПО; подробную информацию см. в документации Kerberos. Следующий пример показывает, как его сгенерировать с помощью программы kadmin в MIT-совместимых реализациях Kerberos 5:

kadmin% addprinc -randkey postgres/server.my.domain.org
kadmin% ktadd -k krb5.keytab postgres/server.my.domain.org

Для метода аутентификации GSSAPI поддерживаются следующие параметры аутентификации:

include_realm
При значении 0 перед проведением сопоставления имен пользователей из субъекта- службы аутентифицированного пользователя убирается область (см. раздел Файл сопоставления имен пользователей). Этот вариант не рекомендуется и поддерживается в основном для обратной совместимости, поскольку он небезопасен в средах с несколькими областями, если только дополнительно не установить krb_realm. Рекомендуется оставить в include_realm значение по умолчанию (1) и задать в pg_ident.conf явное сопоставление для преобразования имен субъектов-служб в имена пользователей QHB.

map
Разрешает сопоставление субъектов-служб с именами пользователей базы данных. Подробную информацию см. в разделе Файл сопоставления имен пользователей. Для субъекта-службы GSSAPI/Kerberos, такого как username@EXAMPLE.COM (или более редкого username/hostbased@EXAMPLE.COM), именем пользователя в сопоставлении будет username@EXAMPLE.COM (или username/hostbased@EXAMPLE.COM соответственно), если include_realm не равно 0; иначе имя системного пользователя в сопоставлении будет username (или username/hostbased).

krb_realm
Задает область, с которой будут сопоставляться имена субъектов-служб пользователей. Если этот параметр установлен, подключаться смогут только пользователи из этой области. Если он не установлен, подключаться смогут пользователи из любой области, в зависимости от выполняемого сопоставления имен пользователей.

Помимо этих параметров, которые могут отличаться в разных записях файла pg_hba.conf, существует параметр конфигурации уровня сервера krb_caseins_users. Если он равен true, субъекты-службы пользователей сопоставляются с записями пользователей без учета регистра. Если установлен параметр krb_realm, области тоже сопоставляются без учета регистра.

Аутентификация ident

Метод аутентификации ident работает, получая имя пользователя операционной системы клиента от сервера Ident и используя его в качестве разрешенного имени пользователя базы данных (с возможным сопоставлением имен пользователей). Этот метод поддерживается только для подключений по TCP/IP.

Примечание
При указании ident для локального подключения (не TCP/IP), вместо него будет использован метод подключения peer (см. подраздел Аутентификация peer).

Для метода ident поддерживаются следующие параметры конфигурации:

map
Позволяет сопоставить имена пользователей системы и базы данных. Подробную информацию см. в разделе Файл сопоставления имен пользователей.

«Протокол идентификации» (Ident) описан в RFC 1413. Практически каждая Unix- подобная операционная системы поставляется с сервером Ident, по умолчанию прослушивающим TCP-порт 113. Базовая функциональность этого сервера — отвечать на вопросы вроде «Какой пользователь инициировал подключение, которое идет через твой порт X и подключается к моему порту Y?». Поскольку после установления физического подключения QHB знает и X, и Y, она может опрашивать сервер Ident на хосте клиентского подключения и теоретически может определять пользователя операционной системы при каждом подключении.

Недостаток этой процедуры состоит в том, что она зависит от интеграции с клиентом: если компьютер клиента недоверенный или взломанный, злоумышленник может запустить практически любую программу на порту 113 и вернуть любое имя пользователя по своему выбору. Таким образом, этот метод аутентификации подходит только для закрытых сетей, где каждый компьютер клиента находится под строгим контролем и где администраторы операционных систем и баз данных работают в тесном контакте. Другими словами, вы должны доверять компьютеру, на котором работает сервер Ident. Относитесь серьезно к предупреждению:

Протокол идентификации не предназначен для использования в качестве протокола авторизации или управления доступом.

--RFC 1413

У некоторых серверов Ident есть нестандартная функциональность, позволяющая зашифровывать возвращаемое имя пользователя, используя ключ, который известен только администратору исходного компьютера. Эту функциональность нельзя использовать с QHB, так как у QHB нет никакой возможности расшифровать возвращаемую строку и получить фактическое имя пользователя.

Аутентификация peer

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

Для метода peer поддерживаются следующие параметры конфигурации:

Аутентификация peer доступна только в операционных системах, предоставляющих функцию getpeereid(), параметр сокета SO_PEERCRED или схожие механизмы. В настоящее время это Linux, большинство разновидностей BSD, включая macOS, и Solaris.

Аутентификация LDAP

Этот метод аутентификации работает сходным с методом password образом, за исключением того, что он использует LDAP в качестве метода подтверждения пароля. LDAP используется только для подтверждения пар имя пользователя/пароль. Поэтому пользователь должен уже существовать в базе данных до того, как для аутентификации можно будет использовать LDAP.

Аутентификация LDAP может работать в двух режимах. В первом режиме, который мы назовем простым связыванием, сервер связывается с отличительным именем, составленным в виде префикс имя_пользователя суффикс. Как правило, параметр префикс используется для указания cn= или DOMAIN\ в среде Active Directory. Параметр суффикс используется для указания оставшейся части DN в среде, отличной от Active Directory.

Во втором режиме, который мы назовем поиск+связывание, сервер сначала связывается с каталогом LDAP с постоянным именем пользователя и паролем, указанными в ldapbinddn и ldapbindpasswd, и выполняет поиск этого пользователя, пытающегося подключиться к базе данных. Если пользователь и пароль не определены, сервер пытается связаться с каталогом анонимно. Поиск осуществляется в поддереве ldapbasedn с попыткой подобрать точное соответствие атрибуту, заданному в ldapsearchattribute. Как только при поиске находится пользователь, сервер разрывает подключение и заново связывается с каталогом уже как этот пользователь, используя указанный клиентом пароль, чтобы удостовериться, что эта учетная запись корректна. Этот же режим применяется в схемах аутентификации LDAP в другом программном обеспечении, например, в mod_authnz_ldap и pam_ldap в Apache. Этот режим дает гораздо больше гибкости в выборе расположения объектов пользователей в каталоге, но при этом требует дважды подключаться к серверу LDAP.

В обоих режимах используются следующие параметры конфигурации:

ldapserver
Имена или IP-адреса серверов LDAP для подключения. Можно указать несколько серверов, разделяя их пробелами.

ldapport
Номер порта для подключения к серверу LDAP. Если порт не указан, будет использован установленный по умолчанию порт библиотеки LDAP.

ldapscheme
Значение ldaps выбирает протокол LDAPS. Это нестандартный способ использования LDAP поверх SSL, поддерживаемый некоторыми реализациями сервера LDAP. Альтернативный вариант см. в описании параметра ldaptls.

ldaptls
При значении 1 в соединении QHB с сервером LDAP применяется шифрование TLS. При этом используется операция StartTLS, описанная в RFC 4513. Альтернативный вариант см. в описании параметра ldapscheme.

Обратите внимание, что при использовании ldapscheme или ldaptls шифруется только трафик между сервером QHB и сервером LDAP. Соединение между сервером QHB и клиентом QHB останется незашифрованным, если только и для него не применяется SSL.

Следующие параметры используются только в режиме простого связывания:

ldapprefix
Эта строка подставляется перед именем пользователя во время формирования DN для связывания при аутентификации в режиме простого связывания.

ldapsuffix
Эта строка подставляется после имени пользователя во время формирования DN для связывания при аутентификации в режиме простого связывания.

Следующие параметры используются только в режиме поиск+связывание:

ldapbasedn
Корневая папка DN, с которой начинается поиск пользователя при аутентификации в режиме поиск+связывание.

ldapbinddn
DN пользователя для связывания с каталогом при выполнении поиска в ходе аутентификации в режиме поиск+связывание.

ldapbindpasswd
Пароль пользователя для связывания с каталогом при выполнении поиска в ходе аутентификации в режиме поиск+связывание.

ldapsearchattribute
Атрибут для сравнения с именем пользователя при выполнении поиска в ходе аутентификации в режиме поиск+связывание. Если атрибут не указан, будет использован атрибут uid.

ldapsearchfilter
Фильтр поиска, используемый при аутентификации в режиме поиск+связывание. Вхождения $username в нем будут заменяться именем пользователя. Это позволяет задавать более гибкие фильтры поиска, чем ldapsearchattribute.

ldapurl
URL-адрес LDAP согласно стандарту RFC 4516. Это альтернативный способ записи некоторых других параметров LDAP в более компактной и стандартной форме. Формат адреса выглядит так:

ldap[s]://хост[:порт]/basedn[?[атрибут][?[область_действия][?[фильтр]]]]

Элемент область_действия должен иметь значение base, one или sub, обычно последнее. (Значение по умолчанию, base, обычно не очень полезно при таком применении.) В элементе атрибут можно назначить один атрибут; в этом случае он используется как значение параметра ldapsearchattribute. Если атрибут не указан, в качестве значения параметра ldapsearchfilter можно использовать фильтр.

Схема URL-адреса ldaps выбирает для установления LDAP-подключений поверх SSL метод LDAPS, что равнозначно указанию ldapscheme=ldaps. Для применения шифрованных LDAP-подключений с операцией StartTLS используйте обычную схему URL-адреса ldap и в дополнение к параметру ldapurl укажите ldaptls.

Для неанонимных связываний ldapbinddn и ldapbindpasswd следует указывать как отдельные параметры.

В настоящее время URL-адреса LDAP поддерживаются только с OpenLDAP.
.

Не стоит путать параметры конфигурации для режима простого связывания с параметрами для режима поиск+связывание, это будет ошибкой.

В режиме поиск+связывание поиск может выполняться либо по одному атрибуту, заданному в ldapsearchattribute, либо по произвольному фильтру поиска, заданному в ldapsearchfilter. Указание ldapsearchattribute=foo равнозначно указанию ldapsearchfilter="(foo=$username)". Если ни один параметр не указан, по умолчанию подразумевается ldapsearchattribute=uid.

Если QHB была скомпилирована с OpenLDAP в качестве клиентской библиотеки LDAP, параметр ldapserver может быть опущен. В этом случае за списком имен хостов и портов сервер, согласно стандарту RFC 2782, обращается в DNS, к SRV-записи с именем _ldap._tcp.DOMAIN, где DOMAIN извлекается из ldapbasedn.

Пример конфигурации LDAP для простого связывания:

host ... ldap ldapserver=ldap.example.net ldapprefix="cn=" ldapsuffix=", dc=example, dc=net"

Когда запрашивается подключение к серверу базы данных в качестве пользователя базы данных someuser, QHB пытается связаться с сервером LDAP, используя DN cn=someuser, dc=example, dc=net и пароль, предоставленный клиентом. Если это подключение удалось, то доступ к базе данных будет открыт.

Пример конфигурации для режима поиск+связывание:

host ... ldap ldapserver=ldap.example.net ldapbasedn="dc=example, dc=net" ldapsearchattribute=uid

Когда запрашивается подключение к серверу базы данных в качестве пользователя базы данных someuser, QHB пытается связаться с сервером LDAP анонимно (поскольку параметр ldapbinddn не был задан), выполняет поиск для (uid=someuser) под указанным DN базы. Если запись найдена, QHB пытается связаться с использованием этой найденной информации и пароля, предоставленного клиентом. Если это второе подключение удалось, то доступ к базе данных будет открыт.

Пример той же конфигурации для режима поиск+связывание, записанной в виде URL-адреса:

host ... ldap ldapurl="ldap://ldap.example.net/dc=example,dc=net?uid?sub"

Такой же формат URL-адреса используется и другим программным обеспечением, поддерживающим аутентификацию по протоколу LDAP, так что эту конфигурацию будет легче использовать совместно.

Пример конфигурации для режима поиск+связывание, в котором ldapsearchfilter используется вместо ldapsearchattribute для прохождения аутентификации по ID или почтовому адресу пользователя:

host ... ldap ldapserver=ldap.example.net ldapbasedn="dc=example, dc=net" ldapsearchfilter="(|(uid=$username)(mail=$username))"

Пример конфигурации для режима поиск+связывание, в котором используется поиск SRV-записи в DNS для получения имен хостов и портов службы LDAP в домене example.net:

host ... ldap ldapbasedn="dc=example,dc=net"

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

Аутентификация RADIUS

Этот метод аутентификации работает сходным с методом password образом, за исключением того, что он использует RADIUS в качестве метода подтверждения пароля. RADIUS используется только для подтверждения пар имя пользователя/пароль. Поэтому пользователь должен уже существовать в базе данных до того, как для аутентификации можно будет использовать RADIUS.

При использовании аутентификации RADIUS настроенному серверу RADIUS посылается сообщение с запросом доступа. Это запрос типа Authenticate Only (только аутентификация), который включает в себя элементы user name (имя пользователя), password (зашифрованный пароль) и NAS Identifier (идентификатор NAS). Запрос шифруется с использованием общего с сервером секрета. Сервер RADIUS отвечает на этот запрос либо Access Accept (Доступ разрешен), либо Access Reject (В доступе отказано). Система ведения учета для RADIUS отсутствует.

Можно указать несколько серверов RADIUS, тогда они будут перебираться по очереди. Если от любого из серверов будет получен отрицательный ответ, произойдет сбой аутентификации.Если ответ не будет получен, последует попытка подключения к следующему серверу в списке. Чтобы указать несколько серверов, следует разделить их имена запятыми и заключить список в кавычки. При этом все остальные параметры RADIUS тоже можно задать в списках через запятую, чтобы каждый сервер получил отдельное значение. Также их можно задавать одним значением, тогда оно будет применяться ко всем серверам.

Для метода RADIUS поддерживаются следующие параметры конфигурации:

radiusservers
DNS-имена или IP-адреса серверов RADIUS для подключения. Это обязательный параметр.

radiussecrets
Общие секреты, используемые при защищенном обращении к серверам RADIUS. Значение этого параметра должно быть одинаковым на серверах QHB и RADIUS. Рекомендуется использовать стоку как минимум из 16 символов. Это обязательный параметр.

Примечание
Вектор шифрования будет криптографически эффективен только в том случае, если QHB собрана с поддержкой OpenSSL. В остальных случаях передача данных серверу RADIUS следует считать замаскированной, но не защищенной, поэтому при необходимости нужно применить дополнительные меры безопасности.

radiusports
Номера портов для подключения к серверам RADIUS. Если никакой порт не задан, будет использован порт RADIUS по умолчанию (1812).

radiusidentifiers
Сроки, используемые в запросах RADIUS как NAS Identifier. Этот параметр можно использовать, например, для обозначения того, к какому кластеру баз данных пытается подключиться пользователь, что может быть полезно для выбора соответствующей политики на сервере RADIUS. Если никакой идентификатор не задан, по умолчанию будет использован postgresql.

Если в значение параметра RADIUS необходимо добавить запятую или пробел, это можно сделать, заключив это значение в кавычки, но это неудобно, поскольку теперь потребуется два уровня кавычек. Например, так добавляются пробелы в строки секретов RADIUS:

host ... radius radiusservers="server1,server2" radiussecrets="""secret one"",""secret two"""

Аутентификация по сертификату

В данном методе аутентификации используются клиентские сертификаты SSL, поэтому он применим только для подключений SSL. При использовании этого метода аутентификации сервер запросит у клиента предъявления действительного и доверенного сертификата. Пароль у клиента запрашиваться не будет. Атрибут cn (Обычное имя) сертификата сравнивается с запрашиваемым именем пользователя базы данных, и если они совпадают, вход будет разрешен. Если cn отличается от имени пользователя базы данных, то можно использовать сопоставление имен пользователей.

Для аутентификации по сертификату SSL поддерживаются следующие параметры конфигурации:

Указывать параметр clientcert для аутентификации cert излишне, поскольку метод cert по сути является методом trust с параметром clientcert=verify-full.

Аутентификация PAM

Этот метод аутентификации работает сходным с методом password образом, за исключением того, что он использует PAM (Pluggable Authentication Modules, подключаемые модули аутентификации) в качестве механизма аутентификации. По умолчанию имя службы PAM — postgresql . PAM используется только для подтверждения пар имя пользователя/пароль и, при необходимости, имени или IP-адреса подключенного удаленного хоста. Поэтому пользователь должен уже существовать в базе данных до того, как для аутентификации можно будет использовать PAM. Более подробную информацию о PAM см. на странице описания Linux-PAM.

Для метода PAM поддерживаются следующие параметры конфигурации:

pamservice
Имя службы PAM.

pam_use_hostname
Определяет, предоставляется ли модулям PAM через элемент PAM_RHOST IP-адрес или имя удаленного хоста. По умолчанию используется IP-адрес. При значении 1 вместо него используется разрешенное имя хоста. Разрешение имени хоста может привести к задержкам при подключении. (Большинство конфигураций PAM не пользуются этой информацией, так что этот параметр необходим, только если была создана специальная конфигурация PAM, в которой он используется.)

Примечание
Если PAM настроен для чтения /etc/shadow, произойдет сбой аутентификации, потому что сервер QHB запущен не пользователем root. Однако это не имеет значения, когда PAM настроен для использования LDAP или других методов аутентификации.

Аутентификация BSD

Этот метод аутентификации работает сходным с методом password образом, за исключением того, что он использует аутентификацию BSD для подтверждения пароля. Аутентификация BSD используется только для подтверждения пар имя пользователя/ пароль. Поэтому пользователь должен уже существовать в базе данных до того, как для аутентификации можно будет использовать BSD. Инфраструктура аутентификации BSD в настоящее время доступна только в OpenBSD.

Для аутентификации BSD в QHB применяется тип входа auth- postgresql и проверка с классом входа postgresql, если это определено в login.conf. По умолчанию этот класс входа не существует и QHB использует стандартный класс входа.

Примечание
Для применения аутентификации BSD необходимо сначала добавить учетную запись пользователя QHB (то есть пользователя операционной системы, запускающего сервер) в группу auth. Группа auth существует в системах OpenBSD по умолчанию.