<acronym>GSSAPI</acronym> for
    some or all connections.
   </para>

   <para>
    When using <acronym>GSSAPI</acronym> for encryption, it is common to
    use <acronym>GSSAPI</acronym> for authentication as well, since the
    underlying mechanism will determine both client and server identities
    (according to the <acronym>GSSAPI</acronym> implementation) in any
    case.  But this is not required;
    another <productname>PostgreSQL</productname> authentication method
    can be chosen to perform additional verification.
   </para>

   <para>
    Other than configuration of the negotiation
    behavior, <acronym>GSSAPI</acronym> encryption requires no setup beyond
    that which is necessary for GSSAPI authentication.  (For more information
    on configuring that, see <xref linkend="gssapi-auth"/>.)
   </para>
  </sect2>
 </sect1>

 <sect1 id="ssh-tunnels">
  <title>Secure TCP/IP Connections with <application>SSH</application> Tunnels</title>

  <indexterm zone="ssh-tunnels">
   <primary>ssh</primary>
  </indexterm>

  <para>
   It is possible to use <application>SSH</application> to encrypt the network
   connection between clients and a
   <productname>PostgreSQL</productname> server. Done properly, this
   provides an adequately secure network connection, even for non-SSL-capable
   clients.
  </para>

  <para>
   First make sure that an <application>SSH</application> server is
   running properly on the same machine as the
   <productname>PostgreSQL</productname> server and that you can log in using
   <command>ssh</command> as some user;  you then can establish a
   secure tunnel to the remote server.  A secure tunnel listens on a
   local port and forwards all traffic to a port on the remote machine.
   Traffic sent to the remote port can arrive on its
   <literal>localhost</literal> address, or different bind
   address if desired;  it does not appear as coming from your
   local machine.  This command creates a secure tunnel from the client
   machine to the remote machine <literal>foo.com</literal>:
<programlisting>
ssh -L 63333:localhost:5432 joe@foo.com
</programlisting>
   The first number in the <option>-L</option> argument, 63333, is the
   local port number of the tunnel; it can be any unused port.  (IANA
   reserves ports 49152 through 65535 for private use.)  The name or IP
   address after this is the remote bind address you are connecting to,
   i.e., <literal>localhost</literal>, which is the default.  The second
   number, 5432, is the remote end of the tunnel, e.g., the port number
   your database server is using.  In order to connect to the database
   server using this tunnel, you connect to port 63333 on the local
   machine:
<programlisting>
psql -h localhost -p 63333 postgres
</programlisting>
   To the database server it will then look as though you are
   user <literal>joe</literal> on host <literal>foo.com</literal>
   connecting to the <literal>localhost</literal> bind address, and it
   will use whatever authentication procedure was configured for
   connections by that user to that bind address.  Note that the server will not
   think the connection is SSL-encrypted, since in fact it is not
   encrypted