Moving applications into cloud computing environments has provided numerous benefits and many new problems. A typical design in cloud environments places applications inside a private network with access limited to a load balancer and a bastion server. To keep the bastion server as risk-free as possible, it is best to never store keys to the application server, or any secure data, on the server itself. These steps will help you avoid the practice of storing keys on a bastion server.
These steps assume you have a Linux or Unix connection via the command line.
SSH-AGENT must be installed. This is how we will be able to store keys while we tunnel through the bastion.
From our local machine, we will start by loading up the key(s) for our application server(s):
$ ssh-add /path/to/key
A successful add will output:
Identity added: /path/to/key (/path/to/key)
From here you can see what keys are being carried in the current session:
$ ssh-add -l
2048 SHA256:E/gbb4MwIbtsPXKmoHAvbv7n5+d1CsJeHtsvzqbcn4 confluence (RSA)
2048 SHA256:eealksc19/AcfNW1+6Dt0HddNqqI1kisT3uFifIxY bitbucket (RSA)
2048 SHA256:6pUHl5IiQhZAnLKNMyuQUk3k6AuYDSfALEpzd7HDwQ jira (RSA)
Now we can connect to our bastion server and follow through to the application without the app key being present on the bastion server:
$ ssh -Ai /bastion/key user@host
The ‘A’ flag enables the forwarding of the authentication agent connection. You can also specify this on a per-host basis in a configuration file.
The ‘i’ flag is to identify which key to connect to the bastion within this case.
At this point, we should be on the bastion server and able to connect to any server we have loaded into our ssh-agent keyring.
$ ssh user@server
If switching between client environments, you can clear out the keyring:
$ ssh-add -D
