Cet enregistrement intercepte les tentatives de connexion qui utilise les sockets du domaine Unix. Sans enregistrement de ce type, les connexions de sockets du domaine Unix ne sont pas autorisées.

Cet enregistrement intercepte les tentatives de connexion par TCP/IP. Les lignes host s'appliquent à toute tentative de connexion, SSL ou non, ainsi qu'à toute tentative de connexion GSSAPI chiffrée ou non.

Cet enregistrement intercepte les seules tentatives de connexions par TCP/IP qui utilisent le chiffrement SSL.

Pour utiliser cette fonction, le serveur doit être compilé avec le support de SSL. De plus, SSL doit être activé en positionnant le paramètre de configuration ssl (voir la Section 18.9 pour plus d'informations). Dans le cas contraire, l'enregistrement hostssl est ignoré à l'exception d'une alerte dans les traces indiquant qu'il n'y a aucune connexion correspondante.

Cet enregistrement a un comportement opposé à hostssl : il n'intercepte que les tentatives de connexion qui n'utilisent pas SSL.

Cet enregistrement intercepte les tentatives de connexions par TCP/IP, mais seulement si la connexion est faite avec un chiffrement GSSAPI encryption.

Pour utiliser cette fonction, le serveur doit être compilé avec le support de GSSAPI activé. Dans le cas contraire, l'enregistrement hostgssenc est ignoré à l'exception d'une alerte dans les traces indiquant qu'il n'y a aucune connexion correspondante.

Cet enregistrement a un comportement opposé à hostgssenc; il n'intercepte que les tentatives de connexion qui n'utilisent pas le chiffrement GSSAPI.

Indique les noms des bases de données concernées par l'enregistrement. La valeur all indique qu'il concerne toutes les bases de données. Le terme sameuser indique que l'enregistrement coïncide si la base de données demandée a le même nom que l'utilisateur demandé. Le terme samerole indique que l'utilisateur demandé doit être membre du rôle portant le même nom que la base de données demandée (samegroup est obsolète bien qu'il soit toujours accepté comme écriture alternative de samerole.). Les superutilisateurs ne sont pas considérés comme membres d'un rôle dans le cadre de samerole à moins qu'ils ne soient explicitement membres du rôle, de manière directe ou indirecte, et non pas juste par ses droits de superutilisateur. La valeur replication indique que l'enregistrement établit une correspondance si une connexion de réplication physique est demandée. Néanmoins, il n'établit pas de correspondance pour les connexions de réplication logique. Notez que les connexions de réplication ne ciblent pas une base de données particulière alors que les connexions de réplication logique le font. Sinon, c'est le nom d'une base de données PostgreSQL spécifique ou une expression rationnelle. Plusieurs noms de bases et/ou expressions rationnelles peuvent être fournis en les séparant par des virgules.

Si le nom de la base commence par un slash (/), le reste du nom est traité comme une expression rationnelle. (Voir Section 9.7.3.1 pour des détails sur la syntaxe des expressions rationnelles de PostgreSQL.)

Un fichier séparé contenant les noms des bases et les expressions rationnelles peut être indiquant en faisant précéder le nom du fichier par le caractère @.

Indique les utilisateurs de bases de données auxquels cet enregistrement correspond. La valeur all indique qu'il concerne tous les utilisateurs. Dans le cas contraire, il s'agit soit du nom d'un utilisateur spécifique de bases de données, une expression rationnelle (lorsqu'il commence par un slash (/) ou d'un nom de groupe précédé par un + (il n'existe pas de véritable distinction entre les utilisateurs et les groupes dans PostgreSQL ; un + signifie exactement « établit une correspondance pour tous les rôles faisant parti directement ou indirectement de ce rôle » alors qu'un nom sans + établit une correspondance avec ce rôle spécifique). Ainsi, un superutilisateur n'est considéré comme membre d'un rôle que s'il est explicitement membre du rôle, directement ou indirectement, et non pas juste par ses droits de superutilisateur. Plusieurs noms d'utilisateurs et/ou plusieurs expressions rationnelles peuvent être fournies en les séparant par des virgules.

Si le nom de l'utilisateur commence avec un slash (/), le reste du nom est traité comme une expression rationnelle. (Voir Section 9.7.3.1 pour les détails de la syntaxe des expressions rationnelles avec PostgreSQL.)

Un fichier séparé contenant les noms d'utilisateurs et/ou les expressions rationnelles peut être indiqué en précédant le nom du fichier avec un caractère @.

Indique l'adresse IP ou la plage d'adresses IP à laquelle correspond cet enregistrement. Ce champ peut contenir soit un nom de machine (FQDN), soit le suffixe d'un domaine (sous la forme .exemple.com), soit une adresse ou une plage d'adresses IP, soit enfin l'un des mots-clés mentionnés ci-après.

Une plage d'adresses IP est spécifiée en utilisant la notation numérique standard (adresse de début de plage, suivi d'un slash (/) et suivi de la longueur du masque CIDR. La longueur du masque indique le nombre de bits forts pour lesquels une correspondance doit être trouvée avec l'adresse IP du client. Les bits de droite doivent valoir zéro dans l'adresse IP indiquée. Il ne doit y avoir aucune espace entre l'adresse IP, le / et la longueur du masque CIDR.

À la place du CIDR-address, vous pouvez écrire samehost pour correspondre aux adresses IP du serveur ou samenet pour correspondre à toute adresse du sous-réseau auquel le serveur est directement connecté.

Une plage d'adresses IPv4 spécifiée au format CIDR est typiquement 172.20.143.89/32 pour un hôte seul, 172.20.143.0/24 pour un petit réseau ou 10.6.0.0/16 pour un réseau plus grand. Une plage d'adresses IPv6 spécifiée au format CIDR est par exemple ::1/128 pour un hôte seul (dans ce cas la boucle locale IPv6) ou fe80::7a31:c1ff:0000:0000/96 pour un petit réseau. 0.0.0.0/0 représente toutes les adresses IPv4, et ::0/0 représente l'ensemble des adresses IPv6. Pour n'indiquer qu'un seul hôte, on utilise une longueur de masque de 32 pour IPv4 ou 128 pour IPv6. Dans une adresse réseau, ne pas oublier les zéros terminaux.

Une entrée donnée dans le format IPv4 correspondra seulement aux connexions IPv4, et une entrée donnée dans le format IPv6 correspondra seulement aux connexions IPv6, même si l'adresse représentée est dans la plage IPv4-in-IPv6.

La valeur all permet de cibler n'importe quelle adresse IP cliente, samehost n'importe quelle adresse IP du serveur ou samenet pour toute adresse IP faisant partie du même sous-réseau que le serveur.

Si un nom d'hôte est renseigné (dans les faits tout ce qui ne correspond pas à une plage d'adresse ou une plage d'adresses IP, ni à un mot clé, sera traité comme un nom d'hôte), ce nom est comparé au résultat d'une résolution de nom inverse de l'adresse IP du client (ou une recherche DNS inverse si un DNS est utilisé). Les comparaisons de noms d'hôtes ne sont pas sensibles à la casse. En cas de correspondance, une nouvelle recherche récursive de nom sera lancée afin de déterminer que le nom d'hôte concorde bel et bien avec l'adresse IP du client. L'enregistrement n'est validé qu'en cas de concordance entre la résolution inverse et la résolution récursive pour l'adresse IP cliente. (Le nom d'hôte fourni dans le fichier pg_hba.conf doit donc correspondre à au moins l'une des adresses IP fournies par le mécanisme de résolution de noms, sinon l'enregistrement ne sera pas pris en considération. Certains serveurs de noms réseau permettent d'associer une adresse IP à de multiples noms d'hôtes (alias DNS), mais bien souvent le système d'exploitation ne retourne qu'un seul nom d'hôte lors de la résolution d'une adresse IP.)

Un nom d'hôte débutant par un point (.) ciblera le suffixe du nom d'hôte du poste client. Du coup, indiquer .exemple.com correspondra à la machine foo.exemple.com (mais pas au client exemple.com).

Lorsque vous spécifiez des noms d'hôtes dans le fichier pg_hba.conf, vous devez vous assurer que la résolution de noms soit raisonnablement rapide. À défaut, il peut être avantageux de configurer un serveur-cache local pour effectuer la résolution de noms, tel que nscd. Vous pouvez également valider le paramètre de configuration log_hostname afin de retrouver dans les journaux le nom d'hôte du client au lieu de sa simple adresse IP.

Ces champs ne concernent pas les enregistrements local.

Ces champs peuvent être utilisés comme alternative à la notation adresse IP/longueur masque. Au lieu de spécifier la longueur du masque, le masque réel est indiquée dans une colonne distincte. Par exemple, 255.0.0.0 représente une longueur de masque CIDR IPv4 de 8, et 255.255.255.255 représente une longueur de masque de 32.

Ces champs ne concernent pas les enregistrements local.

Indique la méthode d'authentification à utiliser lors d'une connexion via cet enregistrement. Les choix possibles sont résumés ici ; les détails se trouvent dans la Section 20.3. Toutes les options sont en minuscules et traitées avec une sensibilité à la casse, donc même les acronymes comme ldap doivent être écrits en minuscule.

Après le champ auth-method, on peut trouver des champs de la forme nom=valeur qui spécifient des options pour la méthode d'authentification. Les détails sur les options disponibles apparaissent ci-dessous pour chaque méthode d'authentification.

En plus des options spécifiques à une méthode listées ci-dessous, il existe une option d'authentification indépendante de la méthode, appelée clientcert, qui peut être indiquée dans tout enregistrement hostssl. Cette option peut être positionnée à verify-ca ou verify-full. Ces deux options nécessitent que le client présente un certificat valide (de confiance), alors que verify-full valide également que le cn (Common Name) dans le certificat corresponde au nom d'utilisateur ou a une correspondance adéquate. Ce comportement est similaire à la méthode d'authentification cert (voir Section 20.12 ) mais autorise à appairer la vérification du certificat client avec toute méthode d'authentification qui supporte les entrées hostssl.

Pour tous les enregistrements utilisant une authentification par certificat client (autrement dit, ceux qui utilisent la méthode d'authentification cert ou ceux utilisant l'option clientcert), vous pouvez indiquer quel partie du certificat client doit faire correspondance en utilisant l'option clientname. Cette option doit avoir une valeur parmi deux. Si vous indiquez clientname=CN, qui est le comportement par défait, le nom de l'utilisateur doit établir une correspondance avec le Common Name (CN) du certificat. Si vous indiquez à la place clientname=DN, le nom de l'utilisateur doit faire une correspondance avec le Distinguished Name (DN) entier du certificat. Cette option est probablement mieux utilisée en conjonction avec une carte de noms d'utilisateurs. La comparaison est faire avec le DN au format RFC 2253. Pour voir le DN d'un certificat client dans ce format, faire

openssl x509 -in myclient.crt -noout -subject -nameopt RFC2253 | sed "s/^subject=//"

Il est important de faire attention lors de l'utilisation de cette option, tout spécialement lors de l'utilisation d'expression rationnelle avec le DN.

Cette ligne sera remplacée par le contenu du fichier indiqué.

Cette ligne sera remplacée par le contenu du fichier indiqué si le fichier existe. Sinon, un message est tracé pour indiquer que le fichier a été ignoré.

Cette ligne sera remplacée par le contenu de tous les fichiers trouvés dans le répertoire, s'ils ne commencent pas avec un . et s'ils finissent avec .conf. Ils sont traités dans l'ordre des noms de fichier (suivant les règles de la locale C, autrement dit les chiffres avant les lettres, les majuscules avant les minuscules).