La autenticación del cliente está controlada por un archivo de configuración, que tradicionalmente se denomina pg_hba.conf y se almacena en el directorio de datos del clúster de la base de datos. (HBA significa autenticación basada en host). pg_hba.conf El archivo se instala cuando el directorio de datos es inicializado por initdb. Sin embargo, es posible colocar el archivo de configuración de autenticación en otro lugar; consulte el parámetro de configuración hba_file.

El formato general del pg_hba.conf archivo es un conjunto de registros, uno por línea. Las líneas en blanco se ignoran, al igual que cualquier texto después de la # carácter de comentario. Los registros no pueden continuar entre líneas. Un registro se compone de varios campos separados por espacios y / o tabulaciones. Los campos pueden contener espacios en blanco si el valor del campo está entre comillas dobles. Citando una de las palabras clave en una base de datos, usuario o campo de dirección (p. Ej., all o replication) hace que la palabra pierda su significado especial y simplemente haga coincidir una base de datos, un usuario o un host con ese nombre.

Cada registro especifica un tipo de conexión, un rango de direcciones IP del cliente (si es relevante para el tipo de conexión), un nombre de base de datos, un nombre de usuario y el método de autenticación que se utilizará para las conexiones que coincidan con estos parámetros. El primer registro con un tipo de conexión, dirección de cliente, base de datos solicitada y nombre de usuario coincidentes se utiliza para realizar la autenticación. No hay “caer a través“ o “respaldo“: si se elige un registro y la autenticación falla, los registros posteriores no se consideran. Si ningún registro coincide, se deniega el acceso.

Un registro puede tener varios formatos:

localdatabaseuser  auth-method [auth-options]
host          databaseuser  address     auth-method  [auth-options]
hostssl       databaseuser  address     auth-method  [auth-options]
hostnossl     databaseuser  address     auth-method  [auth-options]
hostgssenc    databaseuser  address     auth-method  [auth-options]
hostnogssenc  databaseuser  address     auth-method  [auth-options]
host          databaseuser  IP-address  IP-mask      auth-method  [auth-options]
hostssl       databaseuser  IP-address  IP-mask      auth-method  [auth-options]
hostnossl     databaseuser  IP-address  IP-mask      auth-method  [auth-options]
hostgssenc    databaseuser  IP-address  IP-mask      auth-method  [auth-options]
hostnogssenc  databaseuser  IP-address  IP-mask      auth-method  [auth-options]

El significado de los campos es el siguiente:

local

Este registro coincide con los intentos de conexión que utilizan sockets de dominio Unix. Sin un registro de este tipo, las conexiones de socket de dominio Unix no están permitidas.

host

Este registro coincide con los intentos de conexión realizados mediante TCP / IP. host los registros coinciden con los intentos de conexión SSL o no SSL, así como con los intentos de conexión cifrados GSSAPI o no GSSAPI.

Nota

Las conexiones TCP / IP remotas no serán posibles a menos que el servidor se inicie con un valor apropiado para el parámetro de configuración listen_addresses, ya que el comportamiento predeterminado es escuchar las conexiones TCP / IP solo en la dirección de loopback local. localhost.

hostssl

Este registro coincide con los intentos de conexión realizados mediante TCP / IP, pero solo cuando la conexión se realiza con cifrado SSL.

Para hacer uso de esta opción, el servidor debe estar construido con soporte SSL. Además, SSL debe habilitarse estableciendo el parámetro de configuración ssl (consulte la Sección 18.9 para obtener más información). De lo contrario, el hostssl El registro se ignora, excepto para registrar una advertencia de que no puede coincidir con ninguna conexión.

hostnossl

Este tipo de registro tiene el comportamiento opuesto de hostssl; solo coincide con los intentos de conexión realizados a través de TCP / IP que no utilizan SSL.

hostgssenc

Este registro coincide con los intentos de conexión realizados mediante TCP / IP, pero solo cuando la conexión se realiza con cifrado GSSAPI.

Para hacer uso de esta opción, el servidor debe estar construido con soporte GSSAPI. De lo contrario, el hostgssenc El registro se ignora, excepto para registrar una advertencia de que no puede coincidir con ninguna conexión.

hostnogssenc

Este tipo de registro tiene el comportamiento opuesto a hostgssenc; solo coincide con los intentos de conexión realizados a través de TCP / IP que no utilizan el cifrado GSSAPI.

database

Especifica con qué nombre (s) de base de datos coincide este registro. El valor all especifica que coincide con todas las bases de datos. El valor sameuser especifica que el registro coincide si la base de datos solicitada tiene el mismo nombre que el usuario solicitado. El valor samerole especifica que el usuario solicitado debe ser miembro del rol con el mismo nombre que la base de datos solicitada. (samegroup es una ortografía obsoleta pero aún aceptada de samerole.) Los superusuarios no se consideran miembros de una función a los efectos de samerole a menos que sean explícitamente miembros del rol, directa o indirectamente, y no solo en virtud de ser un superusuario. El valor replication especifica que el registro coincide si se solicita una conexión de replicación física (tenga en cuenta que las conexiones de replicación no especifican ninguna base de datos en particular). De lo contrario, este es el nombre de una base de datos PostgreSQL específica. Se pueden proporcionar varios nombres de bases de datos separándolos con comas. Se puede especificar un archivo separado que contenga los nombres de la base de datos precediendo el nombre del archivo con @.

user

Especifica qué nombre de usuario de la base de datos coincide con este registro. El valor all especifica que coincide con todos los usuarios. De lo contrario, este es el nombre de un usuario de base de datos específico o el nombre de un grupo precedido por +. (Recuerde que no existe una distinción real entre usuarios y grupos en PostgreSQL; una + marca realmente significa “coincidir con cualquiera de los roles que son directa o indirectamente miembros de este rol“, mientras que un nombre sin un + mark coincide solo con ese rol específico). Para este propósito, un superusuario solo se considera miembro de un rol si es explícitamente miembro del rol, directa o indirectamente, y no solo en virtud de ser un superusuario. Se pueden proporcionar varios nombres de usuario separándolos con comas. Se puede especificar un archivo separado que contenga los nombres de usuario precediendo el nombre del archivo con @.

address

Especifica las direcciones de la máquina cliente con las que este registro coincide. Este campo puede contener un nombre de host, un rango de direcciones IP o una de las palabras clave especiales que se mencionan a continuación.

Un rango de direcciones IP se especifica usando notación numérica estándar para la dirección inicial del rango, luego una barra (/) y una longitud de máscara CIDR. La longitud de la máscara indica el número de bits de orden superior de la dirección IP del cliente que deben coincidir. Los bits a la derecha de esto deben ser cero en la dirección IP dada. No debe haber ningún espacio en blanco entre la dirección IP, la /y la longitud de la máscara CIDR.

Ejemplos típicos de un rango de direcciones IPv4 especificado de esta manera son 172.20.143.89/32 para un solo host, o 172.20.143.0/24 para una red pequeña, o 10.6.0.0/16 para uno más grande. Un rango de direcciones IPv6 podría verse como ::1/128 para un solo host (en este caso, la dirección de loopback IPv6) o fe80::7a31:c1ff:0000:0000/96 para una red pequeña. 0.0.0.0/0 representa todas las direcciones IPv4 y ::0/0 representa todas las direcciones IPv6. Para especificar un solo host, use una longitud de máscara de 32 para IPv4 o 128 para IPv6. En una dirección de red, no omita los ceros finales.

Una entrada dada en formato IPv4 coincidirá solo con conexiones IPv4, y una entrada dada en formato IPv6 solo coincidirá con conexiones IPv6, incluso si la dirección representada está en el rango de IPv4 en IPv6. Tenga en cuenta que las entradas en formato IPv6 se rechazarán si la biblioteca C del sistema no admite direcciones IPv6.

También puedes escribir all para que coincida con cualquier dirección IP, samehost para que coincida con cualquiera de las direcciones IP propias del servidor, o samenet para que coincida con cualquier dirección en cualquier subred a la que el servidor esté conectado directamente.

Si se especifica un nombre de host (cualquier cosa que no sea un rango de direcciones IP o una palabra clave especial se trata como un nombre de host), ese nombre se compara con el resultado de una resolución de nombre inversa de la dirección IP del cliente (por ejemplo, DNS inverso búsqueda, si se utiliza DNS). Las comparaciones de nombres de host no distinguen entre mayúsculas y minúsculas. Si hay una coincidencia, entonces se realiza una resolución de nombre de reenvío (por ejemplo, búsqueda de DNS reenviada) en el nombre de host para verificar si alguna de las direcciones a las que se resuelve es igual a la dirección IP del cliente. Si ambas direcciones coinciden, se considera que la entrada coincide. (El nombre de host que se utiliza en pg_hba.conf debe ser el que devuelve la resolución de dirección a nombre de la dirección IP del cliente, de lo contrario, la línea no coincidirá. Algunas bases de datos de nombres de host permiten asociar una dirección IP con varios nombres de host, pero el sistema operativo solo devolverá un nombre de host cuando se le solicite que resuelva una dirección IP).

Una especificación de nombre de host que comienza con un punto (.) coincide con un sufijo del nombre de host real. Entonces .example.com coincidiría foo.example.com (pero no solo example.com).

Cuando los nombres de host se especifican en pg_hba.conf, debe asegurarse de que la resolución de nombres sea razonablemente rápida. Puede resultar ventajoso configurar una memoria caché de resolución de nombres local, como nscd. Además, es posible que desee habilitar el parámetro de configuración log_hostname para ver el nombre de host del cliente en lugar de la dirección IP en el registro.

Estos campos no se aplican a local registros.

Nota

Los usuarios a veces se preguntan por qué los nombres de host se manejan de esta manera aparentemente complicada, con dos resoluciones de nombre que incluyen una búsqueda inversa de la dirección IP del cliente. Esto complica el uso de la función en caso de que la entrada DNS inversa del cliente no esté configurada o produzca un nombre de host no deseado. Se hace principalmente por eficiencia: de esta manera, un intento de conexión requiere como máximo dos búsquedas de resolución, una inversa y otra directa. Si hay un problema de resolución con alguna dirección, se convierte únicamente en un problema de ese cliente. Una implementación alternativa hipotética que solo hiciera búsquedas hacia adelante tendría que resolver todos los nombres de host mencionados en pg_hba.conf durante cada intento de conexión. Eso podría ser bastante lento si se enumeran muchos nombres. Y si hay un problema de resolución con uno de los nombres de host, se convierte en un problema de todos.

Además, es necesaria una búsqueda inversa para implementar la función de coincidencia de sufijos, porque es necesario conocer el nombre de host del cliente real para poder compararlo con el patrón.

Tenga en cuenta que este comportamiento es coherente con otras implementaciones populares de control de acceso basado en nombres de host, como el servidor HTTP Apache y los encapsuladores TCP.

IP-addressIP-mask

Estos dos campos se pueden utilizar como alternativa a la IP-address/mask-length notación. En lugar de especificar la longitud de la máscara, la máscara real se especifica en una columna separada. Por ejemplo, 255.0.0.0 representa una longitud de máscara CIDR IPv4 de 8, y 255.255.255.255 representa una longitud de máscara CIDR de 32.

Estos campos no se aplican a local registros.

auth-method

Especifica el método de autenticación que se utilizará cuando una conexión coincida con este registro. Las posibles opciones se resumen aquí; los detalles se encuentran en la Sección 20.3.

trust

Permita la conexión incondicionalmente. Este método permite que cualquiera que pueda conectarse al servidor de base de datos de PostgreSQL inicie sesión como cualquier usuario de PostgreSQL que desee, sin la necesidad de una contraseña o cualquier otra autenticación. Consulte la Sección 20.4 para obtener más detalles.

reject

Rechaza la conexión incondicionalmente. Este es útil para “filtrando“ ciertos hosts de un grupo, por ejemplo, un reject La línea podría bloquear la conexión de un host específico, mientras que una línea posterior permite que se conecten los hosts restantes en una red específica.

scram-sha-256

Realice la autenticación SCRAM-SHA-256 para verificar la contraseña del usuario. Consulte la Sección 20.5 para obtener más detalles.

md5

Realice la autenticación SCRAM-SHA-256 o MD5 para verificar la contraseña del usuario. Consulte la Sección 20.5 para obtener más detalles.

password

Solicite al cliente que proporcione una contraseña no cifrada para la autenticación. Dado que la contraseña se envía en texto sin cifrar a través de la red, no debe utilizarse en redes que no sean de confianza. Consulte la Sección 20.5 para obtener más detalles.

gss

Utilice GSSAPI para autenticar al usuario. Esto solo está disponible para conexiones TCP / IP. Consulte la Sección 20.6 para obtener más detalles. Se puede utilizar junto con el cifrado GSSAPI.

sspi

Utilice SSPI para autenticar al usuario. Esto solo está disponible en Windows. Consulte la Sección 20.7 para obtener más detalles.

ident

Obtenga el nombre de usuario del sistema operativo del cliente poniéndose en contacto con el servidor de identificación en el cliente y verifique si coincide con el nombre de usuario de la base de datos solicitado. La autenticación de identidad solo se puede utilizar en conexiones TCP / IP. Cuando se especifica para conexiones locales, se utilizará la autenticación de pares en su lugar. Consulte la Sección 20.8 para obtener más detalles.

peer

Obtenga el nombre de usuario del sistema operativo del cliente del sistema operativo y verifique si coincide con el nombre de usuario de la base de datos solicitado. Esto solo está disponible para conexiones locales. Consulte la Sección 20.9 para obtener más detalles.

ldap

Autentíquese mediante un servidor LDAP. Consulte la Sección 20.10 para obtener más detalles.

radius

Autentíquese mediante un servidor RADIUS. Consulte la Sección 20.11 para obtener más detalles.

cert

Autentíquese mediante certificados de cliente SSL. Consulte la Sección 20.12 para obtener más detalles.

pam

Autentíquese mediante el servicio Módulos de autenticación conectables (PAM) que proporciona el sistema operativo. Consulte la Sección 20.13 para obtener más detalles.

bsd

Autentíquese mediante el servicio de autenticación BSD proporcionado por el sistema operativo. Consulte la Sección 20.14 para obtener más detalles.

auth-options

Después de la auth-method campo, puede haber campos del formulario name=value que especifican opciones para el método de autenticación. Los detalles sobre qué opciones están disponibles para qué métodos de autenticación aparecen a continuación.

Además de las opciones específicas del método que se enumeran a continuación, hay una opción de autenticación independiente del método clientcert, que se puede especificar en cualquier hostssl registro. Esta opción se puede establecer en verify-ca o verify-full. Ambas opciones requieren que el cliente presente un certificado SSL válido (confiable), mientras que verify-full además hace cumplir que el cn (Nombre común) en el certificado coincide con el nombre de usuario o una asignación aplicable. Este comportamiento es similar al cert método de autenticación (consulte la Sección 20.12), pero permite emparejar la verificación de certificados de cliente con cualquier método de autenticación que admita hostssl entradas.

Archivos incluidos por @ las construcciones se leen como listas de nombres, que pueden estar separados por espacios en blanco o comas. Los comentarios son introducidos por #, al igual que en pg_hba.confy anidado @ se permiten construcciones. A menos que el nombre de archivo siguiente @ es una ruta absoluta, se considera relativa al directorio que contiene el archivo de referencia.

Desde el pg_hba.conf Los registros se examinan secuencialmente para cada intento de conexión, el orden de los registros es significativo. Por lo general, los registros anteriores tendrán parámetros de coincidencia de conexión estrictos y métodos de autenticación más débiles, mientras que los registros posteriores tendrán parámetros de coincidencia más flexibles y métodos de autenticación más sólidos. Por ejemplo, uno podría desear usar trust autenticación para conexiones TCP / IP locales, pero requiere una contraseña para conexiones TCP / IP remotas. En este caso, un registro que especifique trust la autenticación para conexiones de 127.0.0.1 aparecería antes de un registro que especifica la autenticación de contraseña para un rango más amplio de direcciones IP de cliente permitidas.

los pg_hba.conf El archivo se lee en el inicio y cuando el proceso del servidor principal recibe un SIGHUP señal. Si edita el archivo en un sistema activo, deberá avisar al administrador de correos (usando pg_ctl reload, llamando a la función SQL pg_reload_conf(), o usando kill -HUP) para que vuelva a leer el archivo.

Nota

La afirmación anterior no es cierta en Microsoft Windows: allí, cualquier cambio en el pg_hba.conf El archivo se aplica inmediatamente mediante nuevas conexiones posteriores.

La vista del sistema pg_hba_file_rules puede ser útil para realizar pruebas previas de los cambios en el pg_hba.conf archivo, o para diagnosticar problemas si la carga del archivo no tuvo los efectos deseados. Filas en la vista con valores no nulos error Los campos indican problemas en las líneas correspondientes del archivo.

Propina

Para conectarse a una base de datos en particular, un usuario no solo debe pasar el pg_hba.conf cheques, pero debe tener el CONNECT privilegio para la base de datos. Si desea restringir qué usuarios pueden conectarse a qué bases de datos, generalmente es más fácil controlar esto otorgando / revocando CONNECT privilegio que poner las reglas en pg_hba.conf entradas.

Algunos ejemplos de pg_hba.conf Las entradas se muestran en el Ejemplo 20.1. Consulte la siguiente sección para obtener detalles sobre los diferentes métodos de autenticación.

Ejemplo 20.1. Ejemplo pg_hba.conf Entradas

# 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            ADDRESS                 METHODlocalallall                                     trust

# The same using local loopback TCP/IP connections.## TYPE  DATABASE        USER            ADDRESS                 METHOD
host    allall127.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    allall127.0.0.1255.255.255.255     trust

# The same over IPv6.## TYPE  DATABASE        USER            ADDRESS                 METHOD
host    allall             ::1/128                 trust

# The same using a host name (would typically cover both IPv4 and IPv6).## TYPE  DATABASE        USER            ADDRESS                 METHOD
host    allall             localhost               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            ADDRESS                 METHOD
host    postgres        all192.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            ADDRESS                 METHOD
host    postgres        all192.168.12.10/32        scram-sha-256# Allow any user from hosts in the example.com domain to connect to# any database if the user's password is correctly supplied.## Require SCRAM authentication for most users, but make an exception# for user 'mike', who uses an older client that doesn't support SCRAM# authentication.## TYPE  DATABASE        USER            ADDRESS                 METHOD
host    all             mike            .example.com            md5
host    allall.example.com            scram-sha-256# In the absence of preceding "host" lines, these three lines will# reject all connections from 192.168.54.1 (since that entry will be# matched first), but allow GSSAPI-encrypted 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.  Unencrypted GSSAPI connections# (which "fall through" to the third line since "hostgssenc" only matches# encrypted GSSAPI connections) are allowed, but only from 192.168.12.10.## TYPE  DATABASE        USER            ADDRESS                 METHOD
host    allall192.168.54.1/32         reject
hostgssenc allall0.0.0.0/0               gss
host    allall192.168.12.10/32        gss

# 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            ADDRESS                 METHOD
host    allall192.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            ADDRESS                 METHODlocal   sameuser        all                                     md5
localall@admins                                 md5
localall+support                                md5

# The last two lines above can be combined into a single line:localall@admins,+support                        md5

# The database column can also use lists and file names:local   db1,db2,@demodbsall                                   md5
Anterior Hasta próximo
Capítulo 20. Autenticación del cliente Hogar 20.2. Mapas de nombres de usuario