Self Service Bastion Deployment

Intro

In this post we will set up a self service Bastion host to provide secure connectivity to our Oracle Cloud environment. Typically I use this method when I need quickly need access (less than 5 minutes) and I don’t have a high bandwidth requirement. The deployment steps for a self service Bastion are so easy it might surprise you! You don’t even need to SSH into the instance before you can use it as a proxy.

Here are the applications we will use to connect to our Bastion Host.

SSHuttle – an application that turns your Bastion Host into a Pseudo VPN

SSH client – the native SSH client that can port forward traffic from on your local machine to OCI.

Consider This:

Multi-user access, IAM integration, high availability and many other considerations. If you are looking at these features, I recommend using the Bastion as a service that is built in to OCI.

Deployment

To deploy a self service bastion, the steps are very easy. The deployment will start with a newly deployed Oracle Linux Instance to a Public Subnet in the same VCN as the resources you want to access. Once deployed, the instance needs to be allowed access to the back end services. After deploying the Oracle Linux instance there are two options to connect to your OCI resources.

1.) Follow the first blog post to understand how to configure your security lists and other parameters.

2.) Go into the Oracle Cloud Console and deploy an Oracle Linux instance in a Public Subnet where your VCN resources are located. Make sure that your instance has a public IP address assigned and you have the correct SSH keypair to connect to this instance after deployment.

3.) On the Bastion Host Security List add your public IP address to the “ingress” with port 22. An allow 0.0.0.0/0 rule is not a best practice but can be used to allow access to your Bastion Host from any public IP address.

Access Your OCI Environment – SSHuttle

SSHuttle is my favorite way to connect to OCI resources using a self service Bastion. Connectivity to the Bastion is quick and has a VPN-like experience, allowing you to connect to all of your Bastion Targets with one Bastion connection. Additionally, you can also connect to your instances from the Private FQDN. No more certificate errors for using a private IP when you should be using a FQDN!

To install SSHuttle, go to GitHub and find the installation for your operating system.

https://github.com/sshuttle/sshuttle

Once SSHuttle is installed, run the following command to forward 10.0.0.0/16 traffic to your Bastion Host and proxy DNS requests.

Now connect to your resources within the VCN by referencing their private IP address or DNS name directly on your machine. That was almost too easy!

For Windows Users:

SSHuttle does not natively support Windows. There are two workarounds to make SSHuttle work using WSL (Windows Subsystem Linux).

1.) WSSHuttle – a shell script that makes SSHuttle compatible with WSL.

https://github.com/yabeenico/wsshuttle

2.) Statically assign routes based on the Windows and WSL interfaces. Windows does not route this traffic between WSL and Windows by default. This route will allow SSHuttle to be run in WSL and have Windows use it as a proxy.

Find the interface ID that you want to add from CMD.

From CMD:

Add a route for the traffic you want to forward within WSL.

From Bash/WSL:

SSHuttle can now forward traffic properly within WSL by installing directly to WSL.

TIP:

As of the writing of this article, I have not been able to get private DNS to forward properly with WSL. Traffic forwarding using a private IP address works properly.

Access Your OCI Environment – SSH Port Forwarding

If you do not have the ability to install SSHuttle on the client machine you can using port forwarding to create 1:1 mappings from your desktop to OCI. The command below set up a tunnel to your Bastion Host and forward traffic that is destined to OCI resource 10.0.0.105 that hosts RDP (port 3389). To connect on your local machine, go to your RDP client and connect with “127.0.0.1:25000” (25000 is the ephemeral port) after the SSH command is run succuessfully.

Example:

Be Aware! Accessing multiple OCI resources with SSH Port Forwarding is not as easy as SSHuttle since every OCI IP/PORT that needs to be reached needs a separate port forwarding session. I wrote some scripts to automate the predicament in the OCI Bastion Service Connectivity Deep Dive. You can use this as sample code if you choose to automate the 1:1 session mapping problem.

“Unable to negotiate with 111.222.333.444 port 22: no matching host key type found. Their offer: ssh-rsa”

While connecting to your Bastion host, you may see the error above. Starting in Open_SSH8.8, ssh-rsa keys are not allowed by default.

You can append these flags to your SSH command to allow ssh-rsa keys specifically for your Bastion host.

OR

Add this configuration to your ~/.ssh/config file

“My sessions close 5 minutes after I start them”

Port forwarding session will close the session after 5 minutes of inactivity. Set up a server alive interval which will send a probe through your tunnel to keep the tunnel up. 

Add this flag to your SSH command:

OR

Add this configuration to your ~/.ssh/config file

Outro

In this post we walked through a few examples how to quickly gain secure connectivity over the internet to your OCI resources. I hope you enjoyed the post!