Best Practices from Oracle Development's A‑Team

Preparing SSH Tunneling for Oracle Analytics Cloud Remote Data Gateway in a Private Subnet


Note: Private Access Channel is now available in Oracle Analytics and is recommended by Oracle for new connections to private data sources. For more information on the feature and the data sources it supports refer to:
    Connect to Private Data Sources Through a Private Access Channel
    Supported Data Sources
    A-Team Chronicles Private Access Channel Series


The latest releases of Oracle Analytics Cloud (OAC) now include the new Remote Data Gateway (RDG) for accessing databases that are not otherwise accessible by OAC.

This post is a step-by-step guide to configuring an SSH Client to reach an RDG host (app-server) in a private subnet via a bastion host in a public subnet. For VPN / FastConnect users, it may be helpful but the bastion is not necessary.

This post is one of the strategies noted in the companion blog Deploying Oracle Analytics Cloud Remote Data Gateway in a Private Subnet


March 17, 2020 for Linux 7.7 and MacOS 10.13.6


MacBook Pro OS 10.13.6 

Linux 7.7

SSH Client (MacOS) OpenSSH_7.8p1

SSH Server (Linux) OpenSSH_7.4p1

Bitvise SSH Server 8.41 (WinOS)


Before You Begin

Preparing the SSH Client

Validating the SSH Tunnel

Validating SSH Client File Transfer to the app-server

Validating SSH Commands to the app-server

Validating SSH Local Port Forwarding to the app-server

 Before You Begin

This post uses a Public/Private key pair for authentication. SSH Tunneling requires the following prerequisites.

Client Prerequisites

An SSH client.

SSH private key(s) corresponding to the public key(s) on the SSH hosts.

Basic OCI Prerequisites

The following must be in place. Links to the relevant documentation are provided.

Compartment to contain Virtual Cloud Network(s) (VCNs) Here

Compartment Privilege Policies to create and manage resources Here

VCN(s) with non-overlapping IP Address Ranges (CIDR blocks). See Overview of Networking for an overview and links to this and the following network components.

A Public and a Private Subnet in the VCN(s).

Gateway Prerequisites

If the Bastion and RDG hosts are in different VCNs then peered gateways and routing rules must be in place. See Here for guidance on peering.

Gateways associated with the subnets allowing outbound traffic from the subnets. See Here for guidance on various gateways.

Route Tables associated with the public and private subnets directing traffic appropriately  See Here for guidance on route tables.

Public Subnet Prerequisites

The public subnet hosting the bastion instance must have the following.

An Internet Gateway for SSH Server responses to the SSH Client.

A Routing Rule in the subnet's Route Tables directing SSH responses to the Internet Gateway. See Here for guidance on route tables.

A compute Instance with access to the app-server Here

An SSH public key corresponding a private key on the SSH client.

An Ingress rules allowing access to port 22. Port 22 is the default for SSH.

Private Subnet Prerequisites

The private subnet hosting the app-server must have the following.

A compute Instance with access back to the bastion host.

An SSH public key corresponding to a private key on the SSH client.

An Ingress rule allowing access to port 22.

The following steps have been tested with the two subnets in the same VCN, locally peered VCNs, and VCNs in different regions remotely peered.

Below are sample diagrams:

 Preparing the SSH Client

This post uses an SSH Client configuration file that contains the addresses of the bastion host and the app-server as well as the paths to the private key for each. The user on the hosts is assumed to be opc. The file is named config and is located in the .ssh folder within a user's home directory e.g. /Users/dcarley/.ssh  It is assumed there are no entries existing in the configuration file for hosts named "bastion" and "app-server".

Bastion Host Entries

User an editor to insert or append lines to the configuration file for the IP address, username and path to the private key. Example lines are below:

App-server Host Entries

User an editor to insert or append lines to the configuration file for the IP address, username, path to the private key, a proxy parameter that uses the bastion host and a local Port Forward of port 8080. Example lines are below:

Validate the Contents

Display the contents of the configuration file and ensure the entries are correct. An example command is below:

cat ~/.ssh/config

Note: the '~' notation means your home directory.

 Preparing the Linux SSH Servers

No preparation is necessary if using standard Oracle Linux images.

 Validating the SSH Tunnel

Run the SSH command to connect to the app-server with the opc user via the bastion host. An example command is below:

ssh app-server

Answer yes for both hosts to continue and the fingerprints are added to the known_hosts file.

The complete output is shown below.

 Validating SSH File Transfer to the app-server

Create a File

Edit or create a file in your home directory to be transferred to the app-server via the bastion host.

The following example uses a file named testfile and has the contents "Hello World". 

echo "Hello World" > ~/testfile

Copy the File

Use scp to copy the file to the opc home directory on the app-server. scp is a program for copying files between computers using the SSH protocol. An example command is below:

scp ~/testfile app-server:/home/opc

Note: the file is not stored on the bastion host before being transferred to the app-server. 

Confirm the Transferred File

Connect to the app-server and display the file.

Use the same ssh app-server again to connect to the app-server.

Use the cat testfile command to display the contents:

Type exit to return to you client session.

Connect to the bastion host to confirm the file is not stored there.

Use the ssh bastion to connect to the bastion host and issue the cat testfile command again:

Type exit to return to you client session.

 Validating SSH Commands to the app-server

You may want to issue a command or commands from your client that runs a program or programs on the app-server. The following creates a local script file, copies it to the server and uses the ssh command on the client to run it on the app-server.

echo "echo Hello World" > localScriptfile.sh; chmod +x localScriptfile.sh;

scp localScriptfile.sh app-server:/home/opc/serverScriptfile.sh

ssh app-server ./serverScriptfile.sh

 Validating SSH Local Port Forwarding to the app-server

To avoid opening a port on a server, SSH can use a Local Port Forward to provide client access to the server port via the SSH port e.g. 22. See here for details. The app-server configuration above shows the Local Port Forward parameter.The following allows  a browser on the client to access port 8080 on the app-server via port 22. 

Note: To avoid a 504 Gateway Timeout Error, ensure the Local port is exactly the same as the RDG port.

Start an SSH session to the app-server

This opens the Local Port Forward

ssh app-server

Connect to a running Linux RDG installation on the app-server listening on HTTP Port 8080

Open a bowser window on the client with the address:



This post described configuring an SSH Client to reach an RDG host (app-server) in a private subnet via a bastion host in a public subnet.

For other posts relating to analytics and data integration visit http://www.ateam-oracle.com/dayne-carley


Join the discussion

Comments ( 1 )
  • Sunkara Friday, September 25, 2020
    Nice documentation. Thanks to Carley.
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha