11.2 OCI Bastion: Managed SSH, Port Forwarding & SOCKS5 Sessions

Why Bastion Replaces Jump Hosts

A traditional jump host is a VM with a public IP that administrators SSH into before reaching private servers. It exposes port 22 to the internet, needs patching and user management, and runs all the time. OCI Bastion is an Oracle-managed service that provides restricted and time-limited access to target resources without public endpoints. Bastions do not incur costs, although they have service limits.

You cannot SSH directly into a bastion or administer it like a host. Instead, you create sessions through it.

Bastions and Sessions

To use a session, a user needs IAM permission, the private key that matches the public key in the session, and a client IP inside the allowlist.

The Three Session Types

1. Managed SSH Session

A managed SSH session gives SSH access to a compute instance. The instance must:

• Run a Linux platform image (Windows is not supported).
• Run an OpenSSH server.
• Run the Oracle Cloud Agent with the Bastion plugin enabled.

The agent is enabled by default on instances created from many Oracle-provided images, but the Bastion plugin is not enabled by default, so you must turn it on before creating a session. Bastion relies on the plugin to set up access on the instance for the life of the session.

2. SSH Port Forwarding Session

An SSH port forwarding session (SSH tunneling) connects a port on your client machine to a specific port on a target IP address or DNS name. It does not need an OpenSSH server or the Oracle Cloud Agent on the target, so it works for:

• Databases: for example, connecting Oracle SQL Developer to the private endpoint of an Autonomous AI Transaction Processing database.
• Windows servers: tunneling RDP on port 3389.
• Web consoles or any other TCP service on a private IP.

A typical connection command looks like this:

ssh -i <private-key> -N -L <local-port>:<target-private-ip>:<target-port> -p 22 <session-ocid>@host.bastion.<region>.oci.oraclecloud.com

3. Dynamic Port Forwarding (SOCKS5) Session

A dynamic port forwarding session gives the same benefits as SSH port forwarding, but instead of one fixed target it creates a tunnel to a target subnet. Your client (for example, a browser configured to use a SOCKS5 proxy) then decides which resource and port to reach. This suits administrators who need to reach several private web consoles during one maintenance window.

Time-to-Live Limits

Sessions are temporary by design. The bastion's maximum session TTL can be set from a minimum of 30 minutes to a maximum of 180 minutes (3 hours), and each session can have its own TTL up to that maximum. When the TTL expires, the session ends and the user must create a new session. You can also delete a session before it expires. Setting the bastion-level TTL to the shortest practical value limits how long a stolen private key could be useful.

Network Design

• Create the bastion with the target subnet where the resources are, or a subnet with routes to them.
• Add security rules or NSG rules on the targets that allow SSH (port 22) or the forwarded ports from the bastion's private IP in the target subnet.
• Keep the client CIDR allowlist as narrow as possible. Avoid 0.0.0.0/0.

Access Control and Monitoring

• IAM policies control who can create bastions and sessions. Separate the people who manage bastions from the people who only create sessions, and scope permissions to compartments.
• OCI Audit records every call to the Bastion API, such as session creation, including the requesting principal.
• Monitoring provides Bastion metrics, and Events let you react when bastions or sessions change state.
• Cloud Guard activity detectors include rules for "Bastion created" and "Bastion session created", which can alert the security team.

Oracle also recommends integrating target instances with IAM and multifactor authentication and auditing Bastion operations as part of securing the service.