2 $Header: /cvsroot/pgsql/doc/src/sgml/client-auth.sgml,v 1.42 2002/12/03 21:50:44 momjian Exp $
5 <chapter id="client-authentication">
6 <title>Client Authentication</title>
8 <indexterm zone="client-authentication">
9 <primary>client authentication</primary>
13 When a client application connects to the database server, it
14 specifies which <productname>PostgreSQL</productname> user name it
15 wants to connect as, much the same way one logs into a Unix computer
16 as a particular user. Within the SQL environment the active database
17 user name determines access privileges to database objects -- see
18 <xref linkend="user-manag"> for more information. Therefore, it is
19 essential to restrict which database users can connect.
23 <firstterm>Authentication</firstterm> is the process by which the
24 database server establishes the identity of the client, and by
25 extension determines whether the client application (or the user
26 who runs the client application) is permitted to connect with the
27 user name that was requested.
31 <productname>PostgreSQL</productname> offers a number of different
32 client authentication methods. The method used to authenticate a
33 particular client connection can be selected on the basis of
34 (client) host address, database, and user.
38 <productname>PostgreSQL</productname> user names are logically
39 separate from user names of the operating system in which the server
40 runs. If all the users of a particular server also have accounts on
41 the server's machine, it makes sense to assign database user names
42 that match their operating system user names. However, a server that
43 accepts remote connections may have many users who have no local
44 account, and in such cases there need be no connection between
45 database user names and OS user names.
48 <sect1 id="auth-pg-hba-conf">
49 <title>The <filename>pg_hba.conf</filename> file</title>
51 <indexterm zone="auth-pg-hba-conf">
52 <primary>pg_hba.conf</primary>
56 Client authentication is controlled by the file
57 <filename>pg_hba.conf</filename> in the data directory, e.g.,
58 <filename>/usr/local/pgsql/data/pg_hba.conf</filename>.
59 (<acronym>HBA</> stands for host-based authentication.) A default
60 <filename>pg_hba.conf</filename> file is installed when the data
61 directory is initialized by <command>initdb</command>.
65 The general format of the <filename>pg_hba.conf</filename> file is
66 a set of records, one per line. Blank lines are ignored, as is any
67 text after the <quote>#</quote> comment character. A record is made
68 up of a number of fields which are separated by spaces and/or tabs.
69 Fields can contain white space if the field value is quoted. Records
70 cannot be continued across lines.
74 Each record specifies a connection type, a client IP address range
75 (if relevant for the connection type), a database name, a user name,
76 and the authentication method to be used for connections matching
77 these parameters. The first record with a matching connection type,
78 client address, requested database, and user name is used to perform
79 authentication. There is no <quote>fall-through</> or
80 <quote>backup</>: if one record is chosen and the authentication
81 fails, subsequent records are not considered. If no record matches,
86 A record may have one of the three formats
88 local <replaceable>database</replaceable> <replaceable>user</replaceable> <replaceable>authentication-method</replaceable> <optional><replaceable>authentication-option</replaceable></optional>
89 host <replaceable>database</replaceable> <replaceable>user</replaceable> <replaceable>IP-address</replaceable> <replaceable>IP-mask</replaceable> <replaceable>authentication-method</replaceable> <optional><replaceable>authentication-option</replaceable></optional>
90 hostssl <replaceable>database</replaceable> <replaceable>user</replaceable> <replaceable>IP-address</replaceable> <replaceable>IP-mask</replaceable> <replaceable>authentication-method</replaceable> <optional><replaceable>authentication-option</replaceable></optional>
92 The meaning of the fields is as follows:
96 <term><literal>local</literal></term>
99 This record matches connection attempts using Unix domain
100 sockets. Without a record of this type, Unix-domain socket
101 connections are disallowed
107 <term><literal>host</literal></term>
110 This record matches connection attempts using TCP/IP networks.
111 Note that TCP/IP connections are disabled unless the server is
112 started with the <option>-i</option> option or the
113 <literal>tcpip_socket</> <filename>postgresql.conf</>
114 configuration parameter is enabled.
120 <term><literal>hostssl</literal></term>
123 This record matches connection attempts using SSL over TCP/IP.
124 <literal>host</literal> records will match either SSL or
125 non-SSL connection attempts, but <literal>hostssl</literal>
126 records require SSL connections.
130 To be able make use of this option the server must be built
131 with SSL support enabled. Furthermore, SSL must be enabled by
132 enabling the option <literal>ssl</literal> in
133 <filename>postgresql.conf</filename> (see <xref
134 linkend="runtime-config">).
140 <term><replaceable>database</replaceable></term>
143 Specifies which databases this record matches. The value
144 <literal>all</literal> specifies that it matches all databases.
145 The value <literal>sameuser</> specifies that the record
146 matches if the requested database has the same name as the
147 requested user. The value <literal>samegroup</> specifies that
148 the requested user must a member of the group with the same
149 name as the requested database. Otherwise, this is the name of
150 a specific <productname>PostgreSQL</productname> database.
151 Multiple database names can be supplied by separating them with
152 commas. A file containing database names can be specified by
153 preceding the file name with <literal>@</>. The file must be in
154 the same directory as <filename>pg_hba.conf</>.
160 <term><replaceable>user</replaceable></term>
163 Specifies which <productname>PostgreSQL</> users this record
164 matches. The value <literal>all</literal> specifies that it
165 matches all users. Otherwise, this is the name of a specific
166 <productname>PostgreSQL</productname> user. Multiple user names
167 can be supplied by separating them with commas. Group names can
168 be specified by preceding the group name with <literal>+</>. A
169 file containing user names can be specified by preceding the
170 file name with <literal>@</>. The file must be in the same
171 directory as <filename>pg_hba.conf</>.
177 <term><replaceable>IP-address</replaceable></term>
178 <term><replaceable>IP-mask</replaceable></term>
181 These two fields contain IP address/mask values in standard
182 dotted decimal notation. (IP addresses can only be specified
183 numerically, not as domain or host names.) Taken together they
184 specify the client machine IP addresses that this record
185 matches. The precise logic is that
188 <programlisting>(<replaceable>actual-IP-address</replaceable> xor <replaceable>IP-address-field</replaceable>) and <replaceable>IP-mask-field</replaceable></programlisting>
191 must be zero for the record to match. (Of course IP addresses
192 can be spoofed but this consideration is beyond the scope of
193 <productname>PostgreSQL</productname>.)
197 These fields only apply to <literal>host</literal> and
198 <literal>hostssl</literal> records.
204 <term><replaceable>authentication-method</replaceable></term>
207 Specifies the authentication method to use when connecting via
208 this record. The possible choices are summarized here; details
209 are in <xref linkend="auth-methods">.
213 <term><literal>trust</></term>
216 The connection is allowed unconditionally. This method
217 allows anyone that can connect to the
218 <productname>PostgreSQL</productname> database to login as
219 any <productname>PostgreSQL</productname> user they like,
220 without the need for a password. See <xref
221 linkend="auth-trust"> for details.
227 <term><literal>reject</></term>
230 The connection is rejected unconditionally. This is useful for
231 <quote>filtering out</> certain hosts from a group.
237 <term><literal>md5</></term>
240 Requires the client to supply an MD5 encrypted password for
241 authentication. This is the only method that allows encrypted
242 passwords to be stored in <structname>pg_shadow</structname>.
243 See <xref linkend="auth-password"> for details.
249 <term><literal>crypt</></term>
252 Like <literal>md5</literal> method but uses older crypt
253 encryption, which is needed for pre-7.2 clients.
254 <literal>md5</literal> is preferred for 7.2 and later clients.
255 See <xref linkend="auth-password"> for details.
261 <term><literal>password</></term>
264 Same as "md5", but the password is sent in clear text over the
265 network. This should not be used on untrusted networks.
266 See <xref linkend="auth-password"> for details.
272 <term><literal>krb4</></term>
275 Kerberos V4 is used to authenticate the user. This is only
276 available for TCP/IP connections. See <xref
277 linkend="kerberos-auth"> for details.
283 <term><literal>krb5</></term>
286 Kerberos V5 is used to authenticate the user. This is only
287 available for TCP/IP connections. See <xref
288 linkend="kerberos-auth"> for details.
294 <term><literal>ident</></term>
297 Obtain the operating system user name of the client (for
298 TCP/IP connections by contacting the ident server on the
299 client, for local connections by getting it from the
300 operating system) and check if the user is allowed to
301 connect as the requested database user by consulting the map
302 specified after the <literal>ident</literal> key word.
306 If you use the map <literal>sameuser</literal>, the user
307 names are assumed to be identical. If not, the map name is
308 looked up in the file <filename>pg_ident.conf</filename>
309 in the same directory as <filename>pg_hba.conf</filename>.
310 The connection is accepted if that file contains an
311 entry for this map name with the ident-supplied user name
312 and the requested <productname>PostgreSQL</productname> user
317 For local connections, this only works on machines that
318 support Unix-domain socket credentials (currently
319 <systemitem class=osname>Linux</>, <systemitem
320 class=osname>FreeBSD</>, <systemitem class=osname>NetBSD</>,
321 <systemitem class=osname>OpenBSD</>, and
322 <systemitem class=osname>BSD/OS</>).
326 See <xref linkend="auth-ident"> below for details.
332 <term><literal>pam</></term>
335 Authenticate using the Pluggable Authentication Modules
336 (PAM) service provided by the operating system. See <xref
337 linkend="auth-pam"> for details.
348 <term><replaceable>authentication-option</replaceable></term>
351 The meaning of this optional field depends on the chosen
352 authentication method and is described in the next section.
360 Since the <filename>pg_hba.conf</filename> records are examined
361 sequentially for each connection attempt, the order of the records is
362 significant. Typically, earlier records will have tight connection
363 match parameters and weaker authentication methods, while later
364 records will have looser match parameters and stronger authentication
365 methods. For example, one might wish to use <literal>trust</>
366 authentication for local TCP connections but require a password for
367 remote TCP connections. In this case a record specifying
368 <literal>trust</> authentication for connections from 127.0.0.1 would
369 appear before a record specifying password authentication for a wider
370 range of allowed client IP addresses.
375 Do not prevent the superuser from accessing the template1
376 database. Various utility commands need access to template1.
382 <primary>SIGHUP</primary>
384 The <filename>pg_hba.conf</filename> file is read on start-up and when
385 the <application>postmaster</> receives a
386 <systemitem>SIGHUP</systemitem> signal. If you edit the file on an
387 active system, you will need to signal the <application>postmaster</>
388 (using <literal>pg_ctl reload</> or <literal>kill -HUP</>) to make it
393 An example of a <filename>pg_hba.conf</filename> file is shown in
394 <xref linkend="example-pg-hba.conf">. See below for details on the
395 different authentication methods.
397 <example id="example-pg-hba.conf">
398 <title>An example <filename>pg_hba.conf</filename> file</title>
400 # Allow any user on the local system to connect to any database under
401 # any user name using Unix-domain sockets (the default for local
404 # TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD
407 # The same using local loopback TCP/IP connections.
409 # TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD
410 host all all 127.0.0.1 255.255.255.255 trust
412 # Allow any user from any host with IP address 192.168.93.x to connect
413 # to database "template1" as the same user name that ident reports for
414 # the connection (typically the Unix user name).
416 # TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD
417 host template1 all 192.168.93.0 255.255.255.0 ident sameuser
419 # Allow a user from host 192.168.12.10 to connect to database
420 # "template1" if the user's password is correctly supplied.
422 # TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD
423 host template1 all 192.168.12.10 255.255.255.255 md5
425 # In the absence of preceding "host" lines, these two lines will
426 # reject all connection from 192.168.54.1 (since that entry will be
427 # matched first), but allow Kerberos V connections from anywhere else
428 # on the Internet. The zero mask means that no bits of the host IP
429 # address are considered so it matches any host.
431 # TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD
432 host all all 192.168.54.1 255.255.255.255 reject
433 host all all 0.0.0.0 0.0.0.0 krb5
435 # Allow users from 192.168.x.x hosts to connect to any database, if
436 # they pass the ident check. If, for example, ident says the user is
437 # "bryanh" and he requests to connect as PostgreSQL user "guest1", the
438 # connection is allowed if there is an entry in pg_ident.conf for map
439 # "omicron" that says "bryanh" is allowed to connect as "guest1".
441 # TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD
442 host all all 192.168.0.0 255.255.0.0 ident omicron
444 # If these are the only three lines for local connections, they will
445 # allow local users to connect only to their own databases (databases
446 # with the same name as their user name) except for administrators and
447 # members of group "support" who may connect to all databases. The file
448 # $PGDATA/admins contains a list of user names. Passwords are required in
451 # TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD
452 local sameuser all md5
453 local all @admins md5
454 local all +support md5
456 # The last two lines above can be combined into a single line:
457 local all @admins,+support md5
459 # The database column can also use lists and file names, but not groups:
460 local db1,db2,@demodbs all md5
466 <sect1 id="auth-methods">
467 <title>Authentication methods</title>
469 The following describes the authentication methods in more detail.
472 <sect2 id="auth-trust">
473 <title>Trust authentication</title>
476 When <literal>trust</> authentication is specified,
477 <productname>PostgreSQL</productname> assumes that anyone who can
478 connect to the server is authorized to access the database as
479 whatever database user he specifies (including the database superuser).
480 This method should only be used when there is adequate system-level
481 protection on connections to the postmaster port.
485 <literal>trust</> authentication is appropriate and very convenient
486 for local connections on a single-user workstation. It is usually
487 <emphasis>not</> appropriate by itself on a multiuser machine.
488 However, you may be able to use <literal>trust</> even on a multiuser
489 machine, if you restrict access to the postmaster's socket file using
490 file-system permissions. To do this, set the parameter
491 <varname>unix_socket_permissions</varname> (and possibly
492 <varname>unix_socket_group</varname>) in <filename>postgresql.conf</>,
493 as described in <xref linkend="runtime-config-general">. Or you could
494 set <varname>unix_socket_directory</varname> to place the socket file
495 in a suitably restricted directory.
499 Setting file-system permissions only helps for Unix-socket connections.
500 Local TCP connections are not restricted by it; therefore, if you want
501 to use permissions for local security, remove the <literal>host ...
502 127.0.0.1 ...</> line from <filename>pg_hba.conf</>, or change it to a
503 non-<literal>trust</> authentication method.
507 <literal>trust</> authentication is only suitable for TCP connections
508 if you trust every user on every machine that is allowed to connect
509 to the server by the <filename>pg_hba.conf</> lines that specify
510 <literal>trust</>. It is seldom reasonable to use <literal>trust</>
511 for any TCP connections other than those from <systemitem>localhost</> (127.0.0.1).
516 <sect2 id="auth-password">
517 <title>Password authentication</title>
526 <primary>password</primary>
530 Password-based authentication methods include <literal>md5</>,
531 <literal>crypt</>, and <literal>password</>. These methods operate
532 similarly except for the way that the password is sent across the
533 connection. If you are at all concerned about password
534 <quote>sniffing</> attacks then <literal>md5</> is preferred, with
535 <literal>crypt</> a second choice if you must support pre-7.2
536 clients. Plain <literal>password</> should especially be avoided for
537 connections over the open Internet (unless you use SSL, SSH, or
538 other communications security wrappers around the connection).
542 <productname>PostgreSQL</productname> database passwords are
543 separate from operating system user passwords. The password for
544 each database user is stored in the <literal>pg_shadow</> system
545 catalog table. Passwords can be managed with the query language
546 commands <command>CREATE USER</command> and <command>ALTER
547 USER</command>, e.g., <userinput>CREATE USER foo WITH PASSWORD
548 'secret';</userinput>. By default, that is, if no password has
549 been set up, the stored password is null and
550 password authentication will always fail for that user.
554 To restrict the set of users that are allowed to connect to certain
555 databases, list the users separated by commas, or in a separate
556 file. The file should contain user names separated by commas or one
557 user name per line, and be in the same directory as
558 <filename>pg_hba.conf</>. Mention the (base) name of the file
559 preceded with <literal>@</> in the user column. The
560 database column can similarly accept a list of values or
561 a file name. You can also specify group names by preceding the group
562 name with <literal>+</>.
567 <sect2 id="kerberos-auth">
568 <title>Kerberos authentication</title>
570 <indexterm zone="kerberos-auth">
571 <primary>Kerberos</primary>
575 <productname>Kerberos</productname> is an industry-standard secure
576 authentication system suitable for distributed computing over a
577 public network. A description of the
578 <productname>Kerberos</productname> system is far beyond the scope
579 of this document; in all generality it can be quite complex (yet
580 powerful). The <ulink
581 url="http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html">Kerberos
582 <acronym>FAQ</></ulink> or <ulink
583 url="ftp://athena-dist.mit.edu">MIT Project Athena</ulink> can be
584 a good starting point for exploration. Several sources for
585 <productname>Kerberos</> distributions exist.
589 In order to use <productname>Kerberos</>, support for it must be
590 enabled at build time. See <xref linkend="installation"> for more
591 information. Both Kerberos 4 and 5 are supported, but only one
592 version can be supported in any one build.
596 <productname>PostgreSQL</> operates like a normal Kerberos service.
597 The name of the service principal is
598 <replaceable>servicename/hostname@realm</>, where
599 <replaceable>servicename</> is <literal>postgres</literal> (unless a
600 different service name was selected at configure time with
601 <literal>./configure --with-krb-srvnam=whatever</>).
602 <replaceable>hostname</> is the fully qualified domain name of the
603 server machine. The service principal's realm is the preferred realm
604 of the server machine.
608 Client principals must have their <productname>PostgreSQL</> user
609 name as their first component, for example
610 <replaceable>pgusername/otherstuff@realm</>. At present the realm of
611 the client is not checked by <productname>PostgreSQL</>; so if you
612 have cross-realm authentication enabled, then any principal in any
613 realm that can communicate with yours will be accepted.
617 Make sure that your server key file is readable (and preferably only
618 readable) by the <productname>PostgreSQL</productname> server
619 account (see <xref linkend="postgres-user">). The location of the
620 key file is specified with the <varname>krb_server_keyfile</> run
621 time configuration parameter. (See also <xref
622 linkend="runtime-config">.) The default is <filename>/etc/srvtab</>
623 if you are using Kerberos 4 and
624 <filename>FILE:/usr/local/pgsql/etc/krb5.keytab</> (or whichever
625 directory was specified as <varname>sysconfdir</> at build time)
630 To generate the keytab file, use for example (with version 5)
632 <prompt>kadmin% </><userinput>ank -randkey postgres/server.my.domain.org</>
633 <prompt>kadmin% </><userinput>ktadd -k krb5.keytab postgres/server.my.domain.org</>
635 Read the <productname>Kerberos</> documentation for details.
639 When connecting to the database make sure you have a ticket for a
640 principal matching the requested database user name. An example: For
641 database user name <literal>fred</>, both principal
642 <literal>fred@EXAMPLE.COM</> and
643 <literal>fred/users.example.com@EXAMPLE.COM</> can be used to
644 authenticate to the database server.
648 If you use <application>mod_auth_krb</application> and
649 <application>mod_perl</application> on your
650 <productname>Apache</productname> web server, you can use
651 <literal>AuthType KerberosV5SaveCredentials</literal> with a
652 <application>mod_perl</application> script. This gives secure
653 database access over the web, no extra passwords required.
658 <sect2 id="auth-ident">
659 <title>Ident-based authentication</title>
662 <primary>ident</primary>
666 The ident authentication method works by inspecting the client's
667 operating system user name and determining the allowed database
668 user names by using a map file that lists the permitted
669 corresponding user name pairs. The determination of the client's
670 user name is the security-critical point, and it works differently
671 depending on the connection type.
675 <title>Ident Authentication over TCP/IP</title>
678 The <quote>Identification Protocol</quote> is described in
679 <citetitle>RFC 1413</citetitle>. Virtually every Unix-like
680 operating system ships with an ident server that listens on TCP
681 port 113 by default. The basic functionality of an ident server
682 is to answer questions like <quote>What user initiated the
683 connection that goes out of your port <replaceable>X</replaceable>
684 and connects to my port <replaceable>Y</replaceable>?</quote>.
685 Since <productname>PostgreSQL</> knows both <replaceable>X</> and
686 <replaceable>Y</> when a physical connection is established, it
687 can interrogate the ident server on the host of the connecting
688 client and could theoretically determine the operating system user
689 for any given connection this way.
693 The drawback of this procedure is that it depends on the integrity
694 of the client: if the client machine is untrusted or compromised
695 an attacker could run just about any program on port 113 and
696 return any user name he chooses. This authentication method is
697 therefore only appropriate for closed networks where each client
698 machine is under tight control and where the database and system
699 administrators operate in close contact. In other words, you must
700 trust the machine running the ident server.
703 <attribution>RFC 1413</attribution>
705 The Identification Protocol is not intended as an authorization
706 or access control protocol.
713 <title>Ident Authentication over Local Sockets</title>
716 On systems supporting <symbol>SO_PEERCRED</symbol> requests for
717 Unix-domain sockets (currently <systemitem
718 class="osname">Linux</>, <systemitem class="osname">FreeBSD</>,
719 <systemitem class="osname">NetBSD</>, and <systemitem
720 class="osname">BSD/OS</>), ident authentication can also be applied
721 to local connections. In this case, no security risk is added by
722 using ident authentication; indeed it is a preferable choice for
723 local connections on such systems.
727 On systems without <symbol>SO_PEERCRED</> requests, ident
728 authentication is only available for TCP/IP connections. As a
729 work around, it is possible to specify the <systemitem
730 class="systemname">localhost</> address <systemitem
731 class="systemname">127.0.0.1</> and make connections to this
737 <title>Ident Maps</title>
740 When using ident-based authentication, after having determined the
741 name of the operating system user that initiated the connection,
742 <productname>PostgreSQL</productname> checks whether that user is
743 allowed to connect as the database user he is requesting to connect
744 as. This is controlled by the ident map argument that follows the
745 <literal>ident</> keyword in the <filename>pg_hba.conf</filename>
746 file. There is a predefined ident map <literal>sameuser</literal>,
747 which allows any operating system user to connect as the database
748 user of the same name (if the latter exists). Other maps must be
753 <indexterm><primary>pg_ident.conf</primary></indexterm> Ident maps
754 other than <literal>sameuser</literal> are defined in the file
755 <filename>pg_ident.conf</filename> in the data directory, which
756 contains lines of the general form:
758 <replaceable>map-name</> <replaceable>ident-username</> <replaceable>database-username</>
760 Comments and whitespace are handled in the usual way. The
761 <replaceable>map-name</> is an arbitrary name that will be used to
762 refer to this mapping in <filename>pg_hba.conf</filename>. The other
763 two fields specify which operating system user is allowed to connect
764 as which database user. The same <replaceable>map-name</> can be
765 used repeatedly to specify more user-mappings within a single map.
766 There is no restriction regarding how many database users a given
767 operating system user may correspond to and vice versa.
772 <primary>SIGHUP</primary>
774 The <filename>pg_ident.conf</filename> file is read on start-up and
775 when the <application>postmaster</> receives a
776 <systemitem>SIGHUP</systemitem> signal. If you edit the file on an
777 active system, you will need to signal the <application>postmaster</>
778 (using <literal>pg_ctl reload</> or <literal>kill -HUP</>) to make it
783 A <filename>pg_ident.conf</filename> file that could be used in
784 conjunction with the <filename>pg_hba.conf</> file in <xref
785 linkend="example-pg-hba.conf"> is shown in <xref
786 linkend="example-pg-ident.conf">. In this example setup, anyone
787 logged in to a machine on the 192.168 network that does not have the
788 Unix user name <systemitem>bryanh</>, <systemitem>ann</>, or
789 <systemitem>robert</> would not be granted access. Unix user
790 <systemitem>robert</> would only be allowed access when he tries to
791 connect as <productname>PostgreSQL</> user <systemitem>bob</>, not
792 as <systemitem>robert</> or anyone else. <systemitem>ann</> would
793 only be allowed to connect as <systemitem>ann</>. User
794 <systemitem>bryanh</> would be allowed to connect as either
795 <systemitem>bryanh</> himself or as <systemitem>guest1</>.
798 <example id="example-pg-ident.conf">
799 <title>An example <filename>pg_ident.conf</> file</title>
801 # MAPNAME IDENT-USERNAME PG-USERNAME
803 omicron bryanh bryanh
805 # bob has user name robert on these machines
807 # bryanh can also connect as guest1
808 omicron bryanh guest1
814 <sect2 id="auth-pam">
815 <title>PAM Authentication</title>
818 This authentication type operates similarly to
819 <firstterm>password</firstterm> except that it uses PAM (Pluggable
820 Authentication Modules) as the authentication mechanism. The
821 default PAM service name is <literal>postgresql</literal>. You can
822 optionally supply you own service name after the <literal>pam</>
823 keyword in the file. For more information about PAM, please read
825 url="http://www.kernel.org/pub/linux/libs/pam/"><productname>Linux-PAM</>
826 Page</ulink> and the <ulink
827 url="http://www.sun.com/software/solaris/pam/"><systemitem
828 class="osname">Solaris</> PAM Page</ulink>.
833 <sect1 id="client-authentication-problems">
834 <title>Authentication problems</title>
837 Genuine authentication failures and related problems generally
838 manifest themselves through error messages like the following.
843 No pg_hba.conf entry for host 123.123.123.123, user andym, database testdb
845 This is what you are most likely to get if you succeed in contacting
846 the server, but it does not want to talk to you. As the message
847 suggests, the server refused the connection request because it found
848 no authorizing entry in its <filename>pg_hba.conf</filename>
854 Password authentication failed for user 'andym'
856 Messages like this indicate that you contacted the server, and it is
857 willing to talk to you, but not until you pass the authorization
858 method specified in the <filename>pg_hba.conf</filename> file. Check
859 the password you are providing, or check your Kerberos or ident
860 software if the complaint mentions one of those authentication
866 FATAL 1: user "andym" does not exist
868 The indicated user name was not found.
873 FATAL 1: Database "testdb" does not exist in the system catalog.
875 The database you are trying to connect to does not exist. Note that
876 if you do not specify a database name, it defaults to the database
877 user name, which may or may not be the right thing.
881 Note that the server log may contain more information about an
882 authentication failure than is reported to the client. If you are
883 confused about the reason for a failure, check the log.