- 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:
- 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.
- 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.
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
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 email@example.com
You should now be fully 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:
In our environment, this IP address is 172.31.41.192, so I’ll run:
You should see some login banner information and then get dropped to what looks like the same host:
However, if you issue the
ifconfig command, you should see that we are indeed 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
Brian Johnson, 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.