Bastion Host: What Is It and Do You Really Need It?

Bastion Host: What Is It and Do You Really Need It?

The concept of a bastion host has been around since the early 90s but has evolved drastically with the advent of cloud computing. But how necessary is it?

Have you ever been in a situation where you have a really simple 3-tier application with small to medium utilization and at the same time you would like to stick with the best practices? I was in such a situation and wanted to stay with as simple a solution as possible: a completely serverless static websitе and a back-end hosted on EC2 instance.

What is a bastion host?

The concept of a bastion host first appeared in a 1990 article written by the cybersecurity researcher Marcus J. Ranum. In that article about firewalls, he defined bastion hosts as “a system identified by the firewall administrator as a critical strong point in the network security. Generally, bastion hosts will have some degree of extra attention paid to their security, may undergo regular audits, and may have modified software“.

Put another way, a bastion host is a computer on a network specifically built to withstand attacks. It usually has a single application on it (like a proxy server) to minimize the threat of an attack.

How does a bastion host fit into cloud computing?

In the years since that first article describing bastion hosts, the concept has evolved significantly to include an AWS context. In this context, the bastion host is a „a server whose purpose is to provide access to a private network from an external network, such as the Internet. Because of its exposure to potential attack, a bastion host must minimize the chances of penetration“.

But there’s another AWS context for bastion hosts: that of an EC2 instance. That’s the context we’ll focus on today.

Solution diagram

Getting Started with a Bastion Host

Considering the setup in the example above, you may notice that adding an additional EC2 instance with the role “Bastion Host” will have some financial impact. It also doubles the administrative effort in regard to maintaining the EC2 instances. The financial part of the equation is just a small part of the overhead when it comes to observing AWS best practices. Bastion hosts are helpful but once you introduce such EC2 instances inside your environment, you must carry over to regularly patch the machine, configure its isolation, perform regular audits over it, evaluate access logs, etc. That takes significant effort from a system administration perspective.

OK, Bastion host was recommended by AWS some time ago, but how can we make the solution even more secure with less overhead?

A Bastion-less Security Solution

“Simplicity is the ultimate sophistication” — Leonardo Da Vinci

I firmly believe that quote is the foundation for the AWS philosophy. That’s why they provide the option to manage AWS EC2 instances while using SSH tunnel through AWS Systems Manager. To assist in that, AWS Session Manager allows us to tunnel to another resource within VPC straight from our local machine without maintaining any additional AWS resources like EC2 instance as Bastion host.

There are two main advantages a bastion security solution provides:

  1. It is easy to use — you access your private resources from your local machine without any Bastion/Hopping station and admin effort to support such.
  2. Increased security — There is no need to open any inbound rule publicly.

Solution diagram2

How to implement a bastion-less security solution

  1. Observe the prerequisites

    • Before using Session Manager, we need to ensure that the Operating System is supported. As of today Amazon Linux, Amazon Linux 2, CentOS 6.0+, Oracle Linux 7.5+, RHEL 6.0+, SLES 12+/15+, Ubuntu 12.04 LTS +, macOS Mojave/Catalina (in shortlisted AWS Regions), Windows 2012+ (Windows Server 2016 Nano is not supported).
    • On the EC2 instance which you desire to manage, please install SSM Agent version 2.3.672.0 or later. NB! On Amazon Linux / Amazon Linux 2 this agent is preinstalled, for any other OS there is a guide provided by the vendor.
    • Ensure IAM User/Role of people who will manage the instances has been allowed to performed ssm:StartSession for managed EC2 instance and for resource arn:aws:ssm:::document/AWS-StartSSHSession
    • Create IAM instance profile (if not already created), assign it on the EC2 instance(s) and also add the following IAM Managed policy AmazonSSMManagedInstanceCore to that Role
  2. Prepare your local machine

    • Install on your local machine Session Manager Plugin – either for Windows, macOS or Linux

    • Add the following configuration on your machine:

    • Linux (~/.ssh/config)# SSH over Session Manager

      SSH over Session Manager

      host i-* mi-* ProxyCommand sh -c “aws ssm start-session –target %h –document-name AWS-StartSSHSession –parameters ‘portNumber=%p’”

    • Windows (C:\Users<username>.ssh\config.)

      SSH over Session Manager

      host i-* mi-* ProxyCommand C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe “aws ssm start-session –target %h –document-name AWS-StartSSHSession –parameters portNumber=%p”

    • Ensure your machine has aws cli version 1.16.12 or later

  3. We can now initiate the tunnel, while using the following commands

    ssh -i /path/my-key-pair.pem username@instance-id -L localport:targethost:destport telnet localport

    • Example:

      ssh -i /path/key-pair_instance1.pem username_of_instance1@i-0123456789abcdefa -L ssh -i /path/key-pair_instance1.pem username_of_instance1@ -p 8080

  4. Another way you may find nice to know and use is when you directly use aws cli and you can initiate Interactive session calling just the following command:

    aws ssm start-session
    –target instance-id
    –document-name AWS-StartPortForwardingSession
    –parameters ‘{“portNumber”:[“80”], “localPortNumber”:[“56789”]}’

Bastion Host: Final Thoughts

SSH tunnel via AWS System Manager is a great opportunity to increase the security of your environment. One of the most interesting features the service presents is the ability to have full session logging. You are always in control of who did what, which is a fact that should not be neglected. There is no need to use shared keys for SSH, which is also a huge advantage.

[Originally posted at:] (

comments powered by Disqus