begriffs open source - ai-pg/blob - full-docs/txt/ssh-tunnels.txt

   1
   2 18.11. Secure TCP/IP Connections with SSH Tunnels #
   3
   4    It is possible to use SSH to encrypt the network connection between
   5    clients and a PostgreSQL server. Done properly, this provides an
   6    adequately secure network connection, even for non-SSL-capable clients.
   7
   8    First make sure that an SSH server is running properly on the same
   9    machine as the PostgreSQL server and that you can log in using ssh as
  10    some user; you then can establish a secure tunnel to the remote server.
  11    A secure tunnel listens on a local port and forwards all traffic to a
  12    port on the remote machine. Traffic sent to the remote port can arrive
  13    on its localhost address, or different bind address if desired; it does
  14    not appear as coming from your local machine. This command creates a
  15    secure tunnel from the client machine to the remote machine foo.com:
  16 ssh -L 63333:localhost:5432 joe@foo.com
  17
  18    The first number in the -L argument, 63333, is the local port number of
  19    the tunnel; it can be any unused port. (IANA reserves ports 49152
  20    through 65535 for private use.) The name or IP address after this is
  21    the remote bind address you are connecting to, i.e., localhost, which
  22    is the default. The second number, 5432, is the remote end of the
  23    tunnel, e.g., the port number your database server is using. In order
  24    to connect to the database server using this tunnel, you connect to
  25    port 63333 on the local machine:
  26 psql -h localhost -p 63333 postgres
  27
  28    To the database server it will then look as though you are user joe on
  29    host foo.com connecting to the localhost bind address, and it will use
  30    whatever authentication procedure was configured for connections by
  31    that user to that bind address. Note that the server will not think the
  32    connection is SSL-encrypted, since in fact it is not encrypted between
  33    the SSH server and the PostgreSQL server. This should not pose any
  34    extra security risk because they are on the same machine.
  35
  36    In order for the tunnel setup to succeed you must be allowed to connect
  37    via ssh as joe@foo.com, just as if you had attempted to use ssh to
  38    create a terminal session.
  39
  40    You could also have set up port forwarding as
  41 ssh -L 63333:foo.com:5432 joe@foo.com
  42
  43    but then the database server will see the connection as coming in on
  44    its foo.com bind address, which is not opened by the default setting
  45    listen_addresses = 'localhost'. This is usually not what you want.
  46
  47    If you have to “hop” to the database server via some login host, one
  48    possible setup could look like this:
  49 ssh -L 63333:db.foo.com:5432 joe@shell.foo.com
  50
  51    Note that this way the connection from shell.foo.com to db.foo.com will
  52    not be encrypted by the SSH tunnel. SSH offers quite a few
  53    configuration possibilities when the network is restricted in various
  54    ways. Please refer to the SSH documentation for details.
  55
  56 Tip
  57
  58    Several other applications exist that can provide secure tunnels using
  59    a procedure similar in concept to the one just described.