<img src="https://ws.zoominfo.com/pixel/6169bf9791429100154fc0a2" width="1" height="1" style="display: none;">
Curious about how StrongDM works? 🤔 Learn more here!
Search
Close icon
Search bar icon

How to Create a Bastion Host | Part 1 of a Step-by-step Tutorial

StrongDM manages and audits access to infrastructure.
  • Role-based, attribute-based, & just-in-time access to infrastructure
  • Connect any person or service to any infrastructure, anywhere
  • Logging like you've never seen

Want to secure remote access to a private network? In this series of technical posts, we will share step-by-step instructions to create a Linux bastion host and create an audit trail by logging SSH commands.

The full tutorial is split into three parts:

Part 1: Creating your bastion hosts

  • This post shows you how to create Linux virtual machines in Amazon Web Services, setup virtual networking, and create initial firewall rules to access the hosts.  

Part 2: Managing SSH keys

  • We will show you how to create an SSH key for your bastion host and look at ways you can streamline the bastion host login process without compromising the security of the key.

Part 3: Configuring hosts for logging

  • How to configure our bastion hosts to gather verbose logging data and send it off site to a cloud service.

Part 1: Creating your bastion hosts

What is a bastion host?
A bastion host is a server used to manage access to an internal or private network from an external network - sometimes called a jump box or jump server. Because bastion hosts often sit on the Internet, they typically run a minimum amount of services in order to reduce their attack surface. They are also commonly used to proxy and log communications, such as SSH sessions.

Building an AWS bastion host

First, we will build a bastion host we can use to connect to other internal network hosts. We will use Amazon Web Services, as AWS cloud infrastructure as it’s relatively easy and cost-effective to spin up for demonstration purposes.

Head to the AWS Console and from there, under All Services, choose EC2. From there, click the blue Launch Instance button.

You will be offered a wide variety of Linux systems to choose from. Personally I’m most comfortable with Ubuntu Server 18, so I’ll choose it from the list:

Choosing Ubuntu Server 18 for your AWS bastion host

The next step asks you for an instance type. Our bastion host will really only be used to manage and log connections, so the Free tier eligible selection is fine:

AWS instance type for the bastion server

Next, click Review and Launch at the bottom of the page.

One of the final step asks you to review the instance before launching it. Before we do that, click Edit security groups.

Edit security groups for your AWS jump server

If we leave SSH wide open to the public Internet, it will be prone to brute-force attacks and exploit attempts. Choose to Create a new security group and give it an appropriate name like ssh-from-Internet, then create SSH rules that only allow connections for your team.  You will likely want to allow your corporate office public IP addresses, as well as the IP addresses of staff members who often work from home (i.e. network and system administrators):

On AWS, create a new security group for a jump box

When all your teams IP addresses are added, click Review and Launch.

At the next screen, click Launch.

Finally, you’ll be asked to either create an existing SSH key pair to use with your new jump server, or use a pair you’ve previously established. For this example we will choose Create a new key pair, give it a Key pair name, and then click Download Key Pair before clicking Launch Instances.

Create a new key pair for your jump server

You should then see a screen confirming that your host is launching:

Jump host launching confirmation message

Testing connectivity to the bastion server

Back at the AWS Console under EC2 Instances you should now see your fresh bastion server running:

AWS Console list of your bastion host running

If you click into the white space under Name, you you will see a little pencil icon appear:

Edit the AWS bastion server name

Click the pencil and then give your host a more appropriate name, and then click the checkmark icon:

Confirm AWS bastion host name

From the buttons near the top of the screen, click Connect, and you will be shown a help window with instructions on using SSH to connect to your new bastion server:

Using SSH connect to a new bastion server

We’re using a Mac for this tutorial, so we are going to open the  Terminal command line and go to the directory where our private key file - the one with .pem extension - lives (for more information about private and public keys, see this article), and then type the following:

chmod 400 My2019key.pem

Then, we will issue the following command to connect to the instance:

ssh -i "My2019Key.pem" ubuntu@ec2-52-34-25-159.us-west-2.compute.amazonaws.com 

You will replace ec2-52-34-25-159.us-west-2.compute.amazonaws.com with whatever the fully qualified domain name is of your host. If you’re asked to confirm the connection to the host, press y and Enter, and then you should complete the SSH connection successfully:

Bastion server SSH connection successful

Note: you will by default login as the ubuntu user, but can switch to root access, if needed, using the sudo command.

Changing the bastion server name

You probably noticed that the hostname of the bastion server is shown as an IP address. We will configure a more friendly name by typing:

sudo nano /etc/hostname

Changing bastion server name instead of using the IP

Simply erase the current hostname and type in something that makes sense to you, like bastion-host. Press Control+x, then Y and Enter to save your changes. Next time you reboot, the new host name will take effect.

Creating an internal server to test with

Now that we have our public-facing bastion host configured and locked down to only allow SSH connections from IPs we know and trust, we will create a bastion guest for the bastion host to connect to.

Back at the AWS Console under EC2 Instances you should now see both your bastion host called Bastion Host, as well as the brand new instance, which you can rename to something easier to remember like Bastion Guest.

While you’re in this view, click the Bastion Host and take note of it’s internal IP address, which we will need later. In this example, the IP of the host is 172.31.33.47, which resides on your private subnet in AWS

AWS instance private IP

While you’re here, also take note of the internal IP of your Bastion Guest.

From the left-hand menu, click Security Groups, and then Create Security Group. Give it a name, such as SSH-from-Bastion-host, and then create an SSH rule to only allow the private IP of the Bastion host, which is notated as 172.31.33.47/32.

Create a jump box security group description

Back under the EC2 Instances menu, click Bastion Guest, and then from the Actions menu click Networking → Change Security Groups.

In AWS, under Network and Change Security Groups

From the window that appears, choose your new SSH-from-Bastion-host group and click Assign Security Groups:

AWS interface to assign security groups

At this point, we’ve created our bastion host to allow SSH connections from public IP addresses we specify, and our bastion guest only allows SSH connections from the bastion host’s internal IP address.  

In the next blog post of this series, we will look walk through the steps to secure access using ssh keys, including best practices for key management.

To learn more on how StrongDM helps companies with auditing, make sure to check out our Auditing Use Case.


About the Author

, Security Engineer / Podcaster, is the president of 7 Minute Security, an information security consultancy in the Minneapolis area. Brian spends most of his days helping companies defend their networks.

Since 2004, Brian has also run the blog/podcast called 7 Minute Security, where he shares what he has learned about information security into short, 7-minute chunks.

StrongDM logo
💙 this post?
Then get all that StrongDM goodness, right in your inbox.

You May Also Like

How to Streamline PSD2 Compliance with StrongDM
How to Streamline PSD2 Compliance with StrongDM
In this post, we’ll explore what PSD2 compliance challenges businesses face, and how StrongDM simplifies secure access to help organizations confidently meet PSD2 requirements.
13 StrongDM Use Cases with Real Customer Case Studies
13 StrongDM Use Cases with Real Customer Case Studies
Managing access to critical infrastructure is a challenge for many organizations. Legacy tools often struggle to keep up, creating inefficiencies, security gaps, and frustration. StrongDM offers a modern solution that simplifies access management, strengthens security, and improves workflows. In this post, we’ll explore 13 real-world examples of how StrongDM helps teams solve access challenges and achieve their goals.
How to List All Databases in PostgreSQL (6 Methods)
How to List All Databases in PostgreSQL (6 Methods)
Having a complete view of all your databases in PostgreSQL is essential for effective database management. This guide explores six proven methods you can use to quickly list all of your databases.
How to Connect to a PostgreSQL Database (Remotely)
How to Connect to a Remote PostgreSQL Database
Connecting to a remote PostgreSQL database can prove daunting for some teams. Your organization risks losing valuable time, which then leads to lost productivity. Thankfully, there are four different ways to connect to a remote PostgreSQL database and improve your team's efficiency.
What Is Network Level Authentication (NLA)? (How It Works)
What Is Network Level Authentication (NLA)? (How It Works)
Network Level Authentication (NLA) is a security feature of Microsoft’s Remote Desktop Protocol (RDP) that requires users to authenticate before establishing a remote session. By enforcing this pre-authentication step, NLA reduces the risk of unauthorized access, conserves server resources, and protects against attacks like credential interception and denial of service. While effective in securing RDP sessions, NLA is limited to a single protocol, lacks flexibility, and can add complexity in diverse, modern IT environments that rely on multiple systems and protocols.