18.10. Secure TCP/IP Connections with SSH Tunnels
It is possible to use SSH to encrypt the network connection between clients and a PostgreSQL server. Done properly, this provides an adequately secure network connection, even for non-SSL-capable clients.
  First make sure that an
  
   SSH
  
  server is
   running properly on the same machine as the
  
   PostgreSQL
  
  server and that you can log in using
  
   ssh
  
  as some user. Then you can establish a secure
   tunnel with a command like this from the client machine:
 
ssh -L 63333:localhost:5432 joe@foo.com
  The first number in the
  
   -L
  
  argument, 63333, is the
   port number of your end of the tunnel; it can be any unused port.
   (IANA reserves ports 49152 through 65535 for private use.)  The
   second number, 5432, is the remote end of the tunnel: the port
   number your server is using. The name or IP address between the
   port numbers is the host with the database server you are going to
   connect to, as seen from the host you are logging in to, which
   is
  
   foo.com
  
  in this example. In order to connect
   to the database server using this tunnel, you connect to port 63333
   on the local machine:
 
psql -h localhost -p 63333 postgres
  To the database server it will then look as though you are really
   user
  
   joe
  
  on host
  
   foo.com
  
  connecting to
  
   localhost
  
  in that context, and it
   will use whatever authentication procedure was configured for
   connections from this user and host.  Note that the server will not
   think the connection is SSL-encrypted, since in fact it is not
   encrypted between the
  
   SSH
  
  server and the
  
   PostgreSQL
  
  server.  This should not pose any
   extra security risk as long as they are on the same machine.
 
  In order for the
   tunnel setup to succeed you must be allowed to connect via
  
   ssh
  
  as
  
   joe@foo.com
  
  , just
   as if you had attempted to use
  
   ssh
  
  to create a
   terminal session.
 
You could also have set up the port forwarding as
ssh -L 63333:foo.com:5432 joe@foo.com
  but then the database server will see the connection as coming in
   on its
  
   foo.com
  
  interface, which is not opened by
   the default setting
  
   listen_addresses =
   'localhost'
  
  .  This is usually not what you want.
 
If you have to " hop " to the database server via some login host, one possible setup could look like this:
ssh -L 63333:db.foo.com:5432 joe@shell.foo.com
  Note that this way the connection
   from
  
   shell.foo.com
  
  to
  
   db.foo.com
  
  will not be encrypted by the SSH
   tunnel.
   SSH offers quite a few configuration possibilities when the network
   is restricted in various ways.  Please refer to the SSH
   documentation for details.
 
Tip
Several other applications exist that can provide secure tunnels using a procedure similar in concept to the one just described.