Go Bastion(less!) on OCI

Update May 31st, 2021 – Seems like there was documentation bug so I’ve updated part about Agents. They are disabled by default so you need to enable them always if you want to use Bastion Service Managed session.

I’ve always had slight dislike on requiring Bastion (Jump) server on any cloud which is self-managed. Sure, sometimes it’s just needed but too many times people just create the server, open up NSGs wide open and forget to monitor and patch the server. And if you login there, you’ll usually find bunch of keys from there! True story.

With that said, OCI announced their Bastion service which is great addon! Now you don’t need that server provisioned anymore, or you don’t need a public subnet.

You have possibility to use either managed session or port forwarding session to connect to servers. Managed sessions requires Agent enabled on the compute and ssh port forwarding requires IP on your subnet where you’re connecting to and port. OCI documentation says on new compute instances Agent should be enabled by default but you’ll see further down that I had to enable the agent.

How it works?

In short everything is controlled through OCI and you can manage who can do what via normal IAM policies. What you’ll need first is an Bastion “resource”. Resource defines name, VCN and subnet (where you’re connecting to) and who can login from which IP addresses to Bastion.

After you have Bastion created you need to create a session. If you’re using managed SSH session then you need to define SSH key (for the session!), username and which compute you are connecting to.

Remember you always need either Service Gateway or NAT GW for the private subnet so connection can be made!

Here my compute is on private subnet which I defined earlier, from the dropdown you could choose any compute running on that subnet. In the additional settings you can define some additional details like TTL (time-to-live, max 3 hours in May, 2021) after which you need to create new session. You can also define server port you are connecting to or IP address.

Once I’ve created session I can click on three dots on the right and get the SSH command I can use to login.

Remember I allowed connection from 0.0.0.0/0, you’d still need my bastion key for session, server key and have the bastion OCID to login so allowing CIDR block doesn’t straight away give you access to login.

Let’s try it!

I’ll just replace the first key with Bastion key and second key with my server key.

It’s as simple as that. No public subnet needed.

What about SSH port forwarding?

Well it’s like it says, SSH port forwarding. Now I can define server name or IP where I’m connecting to and target port! So if you want to use RDP you just define target port 3389.

SSH command is slightly different so you need to define local port which you will use to connect.

When I connect, I give my Bastion key and port (5500 for example). It will establish SSH session to Bastion. After that you’ll connect with browser, SSH, RDP to localhost 5500 port and it will forward your connection to specified private IP and port.

Summary

I noticed agent for Bastion wasn’t running by default so I had to enable it manually(Bastion Agent isn’t enabled by default and you always need to enable it for compute instance), when I enable it, it will stay as invalid for 5-10 minutes and after that the agent is running and managed session can be established. Note: you don’t need an agent for SSH port forwarding.

Unless you have some other security requirements, using Bastion service is in my opinion the way to go from now forward. It gives better control overall who can access your OCI network and from where. Administrators can control Bastion itself and users can create their own sessions if IAM policies are set correctly.

Many times you might not have VPN or FastConnect available from day one and you still want to be able to connect to your systems, now you can do it without public subnets.

Really like this announcement!

Official Bastion documentation is available here.