How to Connect to Remote Access & Beyond


The problem that we’re seeking to solve is simply:

How do we provide access to our servers in a way that only authorized people have access and have it easily and reliably – i.e. when an IP address changes, authorized people don’t need to worry, admin staff don’t need to change anything and the system is still secure?

The solution is to use a bastion host as a SSH gateway to the devices we manage.

Basic access through gateway
Basic Access through Gateway Instance

By using a Virtual Private Cloud (VPC) on AWS we can access instances which are not exposed to the Internet on port 22 (Secure Shell) or any other port listening for SSH connections.  We still have to secure our Gateway Instance, but it becomes a bastion server with the sole purpose of providing SSH access to the other resources.

Protecting Keys

The bastion host is accessible and open to the Internet on port 22.  Fail2Ban is running on this device to minimize the potential for DDOS attacks.  The Security Group for this Instance allows only port 22 traffic.  But in order to connect securely to the other hosts on the private subnet of the VPC we need to still use certificates and we don’t want to store our certificates on the bastion host (from hereon we’ll refer to this gateway device by it’s DNS name: or simply remoteaccess).

SSH is able to perform key forwarding if ssh-agent is installed locally on the client computer.  If the developer or system administrator is accessing remoteaccess via an Apple OS X device, ssh-agent is already installed.  Adding the key to ssh-agent is done via the command:

You can list the keys that are included in your ssh-agent keychain by passing the -L argument:

If you’re using a Windows workstation, PuTTY has ssh-agent functionality integrated.  A good explanation of using PuTTY and OS X with SSH key forwarding is here.


Once you’ve added your key the SSH command requires only that you ssh to each successive instance:

Note that I was able to connect from remoteaccess even though my private key is not in the ~/.ssh/ directory:

In this way we’re able to use SSH keys without compromising our private keys.



Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.