Jumpboxes: How to avoid storing SSH keys

By: David MacDonald

What is a jumpbox?

A jumpbox, often called a ‘bastion host’, is a server that gives authenticated users an access point from where they can reach internal servers on a private subnet, usually via SSH. To reach a protected server, you would login through the jumpbox and SSH to the protected server you needed access to.

The use of a jumpbox can dramatically reduce the surface area of an attack by requiring that all SSH access to protected infrastructure is funnelled through it. Your servers only need to allow inbound SSH access from one location — the jumpbox.

A common error is to place the SSH keys to those internal servers on the jumpbox. In doing so, you’re creating a risk. This is because if the jumpbox becomes compromised, your keys to the protected servers sitting on the jumpbox become compromised as well.

So what can we do?

This article will show how you can use a jumpbox as a single access point to your protected servers, all without having to copy your private keys to those servers onto the jumpbox itself. This way, if the jumpbox is ever compromised, the attacker won’t be able to find keys that give access to other protected servers in your cloud infrastructure.

TL;DR

A quick way to connect through a jumpbox to a destination server, without having to store your keys on the jumpbox, is to use the -J flag (the jump flag):

ssh -J user@jumpbox user@protected_server

This flag works on Mac and the approach is much more secure since it lets you keep your keys on your machine instead of having them sit on the jumpbox itself. Your local SSH agent will need to be made aware of both keys (via ssh-add) before the jump can be made.

The Scenario

Let’s imagine that you have a set of servers in the cloud in a private network (no external internet gateway) and you need occasional SSH access to these machines. You could open up access routes to these servers from your corporate network directly, but each route would need to be secured and monitored.

Alternatively, we route inbound SSH access through an intermediate server in the network, called a jumpbox, and limit all access to the secure servers so that the only SSH connections allowed to the secure servers are through this box

Let’s see how we can put this together.

Jumping through the jumpbox

We want to connect to the protected server through the jumpbox (since the jumpbox is the only access point to the protected resource) and since we’re security conscious, we want to do this without having to copy any keys onto the jumpbox itself. Here’s how:

Let’s assume that each user has their own user-specific key, e.g. sarah-jumpbox-key.pemfor the jumpbox and that the protected server expects another SSH key, e.g. protected-server-key.pem., and the user 'user'.

We can initiate this jump as follows:

1. Add your user key for the jumpbox to your SSH agent ssh-add sarah-jumpbox-key.pem
2. Add the key for the protected server to your SSH agent ssh-add protected-server-key.pem
3. Initiate the jump: ssh -J sarah@jumpbox_address user@protected_server_address

Voilà! You’ve now connected to the protected server through the jumpbox!

Further thoughts

Securing your jumpbox is important! Don’t forget to set up your security groups / NACLs / firewalls / key rotation to ensure that the jumpbox itself can only be accessed from your corporate environment and authorized users. Additionally, it is good practice to have the jumpbox use separate keys for each user and all user activity to be logged for audit purposes.

Since your users are providing keys, ensure they are using full disk encryption and are following best practices for storing, handling and rotating them. If you’re using AWS, see herefor a way to use CloudWatch to monitor SSH access attempts to EC2 instances. Even better, take your DevOps to the next level with practices that allow you to remove the need for SSH access entirely.