Gregor,

It works. I wrote a brief paper on this in case anyone
else askes. I am going to forward this to Oracle too,
since the first thing they say is "it is not possible
to access such databases using client tools".

Shalom and Regards,

Porus.


Using Client tools such as EzSql or Oracle Enterprise Manager to
connect to databases behind SSH security servers:
----------------------------------------------------------------

This scenario is seen in a number of sites around the world.
Production Oracle databases are frequently set up so that
they can only be accessed through an SSH server using RSA
authentication as follows:

Client PC -> Ssh Server 1 -> Ssh Server 2 (with database)

It is possible to ping Ssh server 1 from the client PC
but not Ssh Server 2, since it is on a different network
and only accessible from Ssh server 1.

In this scenario, it is possible to use Ssh client software
to connect securely to Ssh server 1 and then to Ssh Server 2,
and the end result is a unix terminal session on the database
box. However, the topic of this paper is about using PC client
tools such as EzSql or Oracle Enterpise Manager to connect to
the database on Ssh server 2.

At first glimpse, this doesnt seem possible, but ssh allows
a way to do this known as "Tcp/Ip port forwarding" or "tunnelling".

TCP/IP port forwarding operates by creating a proxy server
for a source port that a TCP/IP service (such as Sql-Net)
uses. The proxy server on the local machine sits and waits
for a connection from a client program (such as SqlPlus or
Ez-Sql) to the source port. F-Secure SSH (the ssh client software)
now forwards the request and also the data over the secure
channel to the remote system, connecting the PC client
program to the destination host and the destination port.

Set up F-secure SSH 1.1 for Windows (the ssh client
software) in the following way:

Properties:
Connection: Remote Host: Host Name: <Ip address or Hostname of Ssh Server 1>
Forwarded TCP/Ip connections: Local
Name: <any descriptive name>
Source port: 1234 <any free port>
Destination host: 127.0.0.1 (see note below)
Destination Port: 1234 <any free port>
Allow Local Connections only: Ticked

(Note: If the destination host is the same host that is to be
connected to for the terminal session, then 127.0.0.1 (localhost)
should be used for the tunnelling to work).

Now connect using the ssh client software to <Ssh Server 1>.
Once in a session on Ssh server 1, you can tunnel from there
to Ssh Server 2 as follows:

ssh -v -L 1234:<Ip address or Host Name of Ssh Server 2>:1521 <Ip address or
Host Name of Ssh Server 2>

This will ensure all (L for Local) connections to port 1234 on Ssh Server 1
will be forwarded to the remote address <Ssh Server 2>:1521 ie. the
listener port on the database machine, if indeed the listener on that
machine is using port 1521. The v option is for verbose, so you
can verify that the forwarding is okay.

Tnsnames.ora on the local pc is to be changed as follows:

PRD1 =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT = 1234))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = PRD1)
    )
  )

This means the PRD1 connection string uses the local PC's port 1234,
and then tunnels through using the ssh PC client to Ssh Server 1, and
tunnels from there to Ssh server 2's port 1521 ie. the listener port.
A database connection can therefore be established.

At this point, it is possible to use client tools on the PC such
as Tnsping, Sqlplus, Ez-Sql, Oracle Enterprise Manager etc. to
connect to the production database Prd1.

The ssh screen needs to be kept active. Various messages are displayed
from time to time, because of the -v option (verbose). For example,
the following is seen when "tnsping prd1" is issued from the client PC:

<ssh server 1>: Connection to port 1234 forwarding to <ssh server 2>:1521
requested.
<ssh server 1>: Allocated channel 1 of type 3.
<ssh server 1>: Channel now open, status bits 0
<ssh server 1>: Channel 1 receives input eof.
<ssh server 1>: Channel 1 closes outgoing data stream.
<ssh server 1>: Channel 1 sends oclosed.
<ssh server 1>: Channel 1 closes incoming data stream.
<ssh server 1>: Channel 1 sends ieof.
<ssh server 1>: Channel 1 receives output closed.
<ssh server 1>: Channel 1 terminates.

Thanks to Gregor Mosheh (Systems Admin, Humboldt Internet) for a push
in the right direction.

Regards,

Porus H. Havewala.


-----Original Message-----
From: Porus Havewala [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 11, 2000 10:42 AM
To: 'Gregor Mosheh'
Cc: '[EMAIL PROTECTED]'
Subject: RE: Question about using client software


Thanks Gregor. Help really appreciated.

Shalom and Regards,

Porus.

-----Original Message-----
From: Gregor Mosheh [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 11, 2000 2:06 AM
To: Porus Havewala
Cc: [EMAIL PROTECTED]
Subject: Re: Question about using client software



You want port forwarding. Check out the FAQ on that. What port forwarding
does is use your existing SSH connection to form a encrypted "tunnel" to
the other end of your connection and then to a target host:port.

Here's how I would do it:

With UNIX SSH, this is set up with the -L flag. In your case, it sounds
like you'd want a chain of two tunnels, or else you'd pass unencrypted SQL
traffic between Server1 and Server2. Setting up the tunnel from your
Client PC to Server1 varies with your client. You'll hafta read the docs
to your client. The example I give here uses UNIX SSH on the end client.

To connect from Client to Server1, use your usual command-line and add in
"-L 666:server1:666"  This creates a tunnel on localhost:666 (that's the
Client) to server1:666. When connecting from Server1 to Server2, use "-L
666:server2:1000" to create a 2nd tunnel connecting server1:666 to
server2:1000.

Now, on your client, fire up the SQL client and point it at 127.0.0.1:666
and you should find yourself talking to Server2's SQL over an encrypted
tunnel. (Of course, use your own port #s as appropriate, 666 and 1000 are
just examples)


--
Gregor Mosheh
[EMAIL PROTECTED]
Systems Admin, Humboldt Internet
707.825.4638


On Mon, 10 Jul 2000 [EMAIL PROTECTED] wrote:

> Hi Ssh users,
>
> Our production database is accessed through an SSH
> server using RSA authentication as follows:
>
> My client -> Ssh Server 1 -> Ssh Server 2 (with database)
>
> I can connect okay using ssh-client on my pc
> and connect to ssh server 1, then ssh from there
> to ssh server 2, using RSA in both cases. What
> I get is a unix terminal session on the
> database box.
>
> However, I like to use client tools on my PC
> such as Oracle Enterprise Manager etc. to connect
> to the database. Is that possible? Any
> techniques/methods to achieve this?
>
> Any help is greatly appreciated.
>
> Regards,
>
> Porus.
>
>

Reply via email to