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. クライアントとPostgreSQLサーバ間のネットワーク接続を暗号化するためにSSHを使うことができます。 正しく行えば、SSL機能がクライアントになくても、これで十分に安全なネットワーク接続を行うことができます。
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>:
まずSSHサーバがPostgreSQLサーバと同じマシン上で正しく起動していて、ssh
を使ってログインできるユーザが存在することを確かめてください。
リモートサーバへ安全なトンネルを確立することができます。
安全なトンネルは、ローカルポートをリッスンし、すべてのトラフィックをリモートマシン上のポートに転送します。
リモートポートに送信されたトラフィックは、localhost
アドレスまたは必要に応じて別のバインドアドレスに到達することができ、ローカルマシンからのトラフィックとは表示されません。
次のコマンドは、クライアントマシンからリモートマシンfoo.com
への安全なトンネルを作成します。
ssh -L 63333:localhost:5432 joe@foo.com
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:
-L
引数の1番目の数字(63333)はトンネルのローカル側のポート番号で、未使用のポートを選択することが可能です。(IANAは49152から65535までのポートを私的使用のため予約しています。)
この後の名前かIPアドレスは、接続先のリモート側のバインドアドレス(デフォルトはlocalhost
)です。
2番目の数字(5432)は、トンネルのリモート側のサーバが使用しているポート番号です。
このトンネルを使ってデータベースサーバに接続するためには、ローカルマシンのポート63333に接続します。
psql -h localhost -p 63333 postgres
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 between the
<application>SSH</application> server and the
<productname>PostgreSQL</productname> server. This should not pose any
extra security risk because they are on the same machine.
データベースサーバにとっては、ユーザがホストfoo.com
上のユーザjoe
であり、localhost
バインドアドレスに接続しているように見え、そのバインドアドレスに対するそのユーザの接続向けに設定された認証手続きが使用されます。
実際、SSHサーバとPostgreSQLサーバとの間は暗号化されていないため、サーバはこの接続がSSLで暗号化されているとみなさないことに注意してください。
それらが、同じマシン上にあるため、セキュリティ上の危険性が増すことはありません。
In order for the
tunnel setup to succeed you must be allowed to connect via
<command>ssh</command> as <literal>joe@foo.com</literal>, just
as if you had attempted to use <command>ssh</command> to create a
terminal session.
トンネルの確立が成功するためには、ssh
を使用して端末セッションを作成したのと同様に、joe@foo.com
ユーザがssh
を通して接続することが許可されていなければいけません。
You could also have set up 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 <literal>foo.com</literal> bind address, which is not opened by
the default setting <literal>listen_addresses =
'localhost'</literal>. This is usually not what you want.
しかしそうすると、データベースサーバはそのfoo.com
バインドアドレスから接続が来たように判断し、デフォルトの設定であるlisten_addresses = 'localhost'
では開かれません。
通常これは好ましいことではありません。
If you have to <quote>hop</quote> 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 <literal>shell.foo.com</literal>
to <literal>db.foo.com</literal> 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.
shell.foo.com
からdb.foo.com
へのこのような接続はSSHトンネルで暗号化されません。
SSHはいろいろな方法でネットワークが制約されているとき、かなりの数の設定可能性を提供しています。
詳細はSSHの文書を参照してください。
Several other applications exist that can provide secure tunnels using a procedure similar in concept to the one just described. ここで説明してきたものと似た概念の手続きを使用して、安全なトンネルを提供可能なアプリケーションが他にもいくつか存在します。