@@ -2679,34 +2679,39 @@ openssl x509 -req -in server.csr -text -days 365 \
2679
2679
First make sure that an <application>SSH</application> server is
2680
2680
running properly on the same machine as the
2681
2681
<productname>PostgreSQL</productname> server and that you can log in using
2682
- <command>ssh</command> as some user. Then you can establish a secure
2683
- tunnel with a command like this from the client machine:
2682
+ <command>ssh</command> as some user; you then can establish a
2683
+ secure tunnel to the remote server. A secure tunnel listens on a
2684
+ local port and forwards all traffic to a port on the remote machine.
2685
+ Traffic sent to the remote port can arrive on its
2686
+ <literal>localhost</literal> address, or different bind
2687
+ address if desired; it does not appear as coming from your
2688
+ local machine. This command creates a secure tunnel from the client
2689
+ machine to the remote machine <literal>foo.com</literal>:
2684
2690
<programlisting>
2685
2691
ssh -L 63333:localhost:5432 joe@foo.com
2686
2692
</programlisting>
2687
2693
The first number in the <option>-L</option> argument, 63333, is the
2688
- port number of your end of the tunnel; it can be any unused port.
2689
- (IANA reserves ports 49152 through 65535 for private use.) The
2690
- second number, 5432, is the remote end of the tunnel: the port
2691
- number your server is using. The name or IP address between the
2692
- port numbers is the host with the database server you are going to
2693
- connect to, as seen from the host you are logging in to, which
2694
- is <literal>foo.com</literal> in this example. In order to connect
2695
- to the database server using this tunnel, you connect to port 63333
2696
- on the local machine:
2694
+ local port number of the tunnel; it can be any unused port. (IANA
2695
+ reserves ports 49152 through 65535 for private use.) The name or IP
2696
+ address after this is the remote bind address you are connecting to,
2697
+ i.e., <literal>localhost</literal>, which is the default. The second
2698
+ number, 5432, is the remote end of the tunnel, e.g., the port number
2699
+ your database server is using. In order to connect to the database
2700
+ server using this tunnel, you connect to port 63333 on the local
2701
+ machine:
2697
2702
<programlisting>
2698
2703
psql -h localhost -p 63333 postgres
2699
2704
</programlisting>
2700
- To the database server it will then look as though you are really
2705
+ To the database server it will then look as though you are
2701
2706
user <literal>joe</literal> on host <literal>foo.com</literal>
2702
- connecting to <literal>localhost</literal> in that context , and it
2707
+ connecting to the <literal>localhost</literal> bind address , and it
2703
2708
will use whatever authentication procedure was configured for
2704
- connections from this user and host . Note that the server will not
2709
+ connections by that user to that bind address . Note that the server will not
2705
2710
think the connection is SSL-encrypted, since in fact it is not
2706
2711
encrypted between the
2707
2712
<application>SSH</application> server and the
2708
2713
<productname>PostgreSQL</productname> server. This should not pose any
2709
- extra security risk as long as they are on the same machine.
2714
+ extra security risk because they are on the same machine.
2710
2715
</para>
2711
2716
2712
2717
<para>
@@ -2718,12 +2723,12 @@ psql -h localhost -p 63333 postgres
2718
2723
</para>
2719
2724
2720
2725
<para>
2721
- You could also have set up the port forwarding as
2726
+ You could also have set up port forwarding as
2722
2727
<programlisting>
2723
2728
ssh -L 63333:foo.com:5432 joe@foo.com
2724
2729
</programlisting>
2725
2730
but then the database server will see the connection as coming in
2726
- on its <literal>foo.com</literal> interface , which is not opened by
2731
+ on its <literal>foo.com</literal> bind address , which is not opened by
2727
2732
the default setting <literal>listen_addresses =
2728
2733
'localhost'</literal>. This is usually not what you want.
2729
2734
</para>
0 commit comments