<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 SSH Through Bastion With Key | Part 2 - 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

In this post, we will show you how to create an SSH key, which will allow only the systems who have that key to access your bastion host.  We will also look at ways you can streamline the bastion host login process without compromising the security of the key.

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.

In the previous section, we walked through installing and configuring a bastion host and guest, and completed some initial network security configurations to lock network access down to only specific IP addresses.  In this post, we will further adjust our bastion hosts to simplify SSH access without weakening the security of the hosts or the key itself.

Configuring ssh-agent

With SSH configuration complete, next we will configure SSH forwarding, which is going to allow us to connect to the bastion host, and then create the subsequent connection to our bastion guest - all without storing our private SSH key on either server.

To configure this on a Mac (see this Amazon knowledge base article for Windows instructions), issue the following command:

ssh-add -K name-of-your-key.pem

Issuing the ssh-add -K commandIf you want to verify the key has been successfully added, issue this command:
ssh-add -L
Verify key has been added

Connecting to the bastion host with ssh-agent

Now you should be able to connect to your bastion host without specifying the .pem file, as it is securely stored on your machine:

ssh -A ubuntu@fully.qualified.domain.name

Connect to bastion host

You should now be fully logged into your bastion host:

Logged into your bastion host

Connecting to the bastion guest

Now that we have ssh-agent working and are fully logged into the bastion host, we should now be able to simply issue an SSH command to connect right to the bastion guest’s internal IP without providing the private key or any credentials. Do this by issuing:

ssh ubuntu@the.internal.ip.address

In our environment, this IP address is 172.31.41.192, so I’ll run:

Issue ssh ubuntu @ IP address

You should see some login banner information and then get dropped to what looks like the same host:

Connecting to bastion guest

However, if you issue the ifconfig command, you should see that we are indeed connected to the private IP corresponding with the bastion guest:

Using ifconfig command, you should see that we are connected to the private IP corresponding with the bastion guest

For now, type exit and Enter to drop your SSH connection back to the bastion host.

At this point we have configured SSH access control to only specific IP addresses, and configured our management system to use the private SSH key as a “forwarder” so we can easily log into both the bastion host and guest systems.  In the third and final part of this series, we will configure our bastion systems to collect verbose log data and then send it to a cloud provider.

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.