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.
This article 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
- 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.
Part 3: Configuring hosts for logging
- In the final post of this series, we will 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
If you want to verify the key has been successfully added, issue this command:
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:
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.