From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | karimelghazouly(at)gmail(dot)com, Pg Docs <pgsql-docs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: small clairifcation |
Date: | 2020-08-28 04:51:49 |
Message-ID: | CAKFQuwZZ2k0p=x1MPwGWQh1v8prq_efvNBs8ncsxrWOyd+45cg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
On Thu, Aug 27, 2020 at 6:17 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> PG Doc comments form <noreply(at)postgresql(dot)org> writes:
> > The following documentation comment has been logged on the website:
> > Page: https://www.postgresql.org/docs/9.5/ssh-tunnels.html
> > Description:
>
> > "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. "
>
> > as a beginner This took me some time to understand what do you mean by
> "your
> > server" "your end of the tunnel "
>
> Hm, do you have a suggestion for better wording?
>
>
I agree on the need for a different perspective here since it reads just
fine once you know what it is talking about.
But absent that maybe a slightly more tutorial flow would be good.
```
First make sure you can connect to the remote machine that is able to
access the PostgreSQL server (in this example the PostgreSQL server is
running on said remote machine).
local> ssh joe(at)foo(dot)com
Once connected, confirm that while on that machine you are able to connect
to the PostgreSQL server via psql.
remote> psql -h localhost -p 5432 postgres
Now that we have confirmed that the two seperate parts are working, the ssh
connection and the psql connection, we can create a tunnel so that we can
execute psql on our local machine but have the PostgreSQL server see the
inbound connection as coming from the remote machine. To do this we need
to set up a server-like process on the local machine to accept the
connection from psql and then transmit the data to the remote machine.
Since psql is looking for a port number to connect to, 5432 when executed
on the remote machine, we need to specify which one to use on the local
machine. For this example we choose 63333 (it can be any number between
49152 and 65535, and must not be in use already [footnote if more detail is
desired]). We are, in effect, merging the ssh and psql commands above into
a hybrid command that maps the remote psql location information to a local
address and port. ssh, in this tunnel mode, always just listens to its
loopback address so only the local port (6333) is required; but both the
remote host (which is using its own loopback address - the localhost thus
refers to this) and port (5432) are needed as that end of the tunnel can
point anywhere visible to the remote machine (foo.com)
local> ssh -L 63333:localhost:5432 joe(at)foo(dot)com
Now we locally launch psql, connecting to localhost:63333, and ssh on
foo.com proxies the stream to its localhost:5432 connection.
local> psql -h localhost -p 63333
```
I haven't considered how or whether the more advanced details would change
if we expand upon and reword the basic section to be more like the above.
I am curious about whether and why this method absolutely guarantees that
the resultant connection within the tunnel is not SSL-encrypted.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2020-08-28 08:02:16 | Re: Document "59.2. Built-in Operator Classes" have a clerical error? |
Previous Message | Tom Lane | 2020-08-28 01:16:51 | Re: small clairifcation |