• 1417
• Tech Tips for Business Owners ,
• 16 Feb

Introduction

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.

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: remoteaccess.counselkit.com 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:

ssh-add -K myPrivateKey.pem
Enter passphrase for myPrivateKey.pem:
Passphrase stored in keychain: myPrivateKey.pem
Identity added: myPrivateKey.pem (myPrivateKey.pem)

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

ssh-add –L

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDHEXAMPLErl25NOrbhgIGQzyO+TYyqbbYEueiELcXtOQH
gEFpMAb1Nb8SSnlxMxiCXwTKd5/lVnmgcbDwBpe7ayQ6idzjHfvoxPsFrI3QSJVQgyNcx0RylX9IjcvJOyw
== myPrivateKey.pem

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.

Connecting

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

kevinritchey ~ $ ssh -A kevinr@remoteaccess.counselkit.com
Last login: Sun Feb 15 21:38:36 2015 from 50-192-9-137-static.hfc.comcastbusiness.net

       __|  __|_  )
       _|  (     /   Amazon Linux AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-ami/2014.09-release-notes/
[kevinr@ip-172-30-3-194 ~]$ ssh -A kevinr@www.lincolnlaw.com
Last login: Sun Feb 15 21:42:33 2015 from ec2-54-152-199-138.compute-1.amazonaws.com

       __|  __|_  )
       _|  (     /   Amazon Linux AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-ami/2014.09-release-notes/
[kevinr@production ~]$

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

kevinritchey ~ $ ssh -A kevinr@remoteaccess.counselkit.com
Last login: Mon Feb 16 19:21:47 2015 from 101.sub-70-192-145.myvzw.com

       __|  __|_  )
       _|  (     /   Amazon Linux AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-ami/2014.09-release-notes/
[kevinr@ip-172-30-3-194 ~]$ ls .ssh/
authorized_keys  known_hosts
[kevinr@ip-172-30-3-194 ~]$ ssh -A kevinr@www.lincolnlaw.com
Last login: Mon Feb 16 19:11:31 2015 from ec2-54-152-199-138.compute-1.amazonaws.com

       __|  __|_  )
       _|  (     /   Amazon Linux AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-ami/2014.09-release-notes/
[kevinr@production ~]$

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