10

We are running a number of environments on EC2 using VPC. In each VPC we have a hardened bastion host configured which is used as the initial SSH entry point into the network.

To access hosts within our private VPC subnets, a user first SSH to the bastion host and then SSH to other hosts within the subnets. To do this the user forwards the SSH keys (downloaded as .pem files from AWS) when they make the initial SSH connection. For example:

ssh -A ec2-user@bastion-host.on.aws
ssh ec2-user@app-server.on.aws

The whole purpose of the bastion host is to allow team members to securely access our environments providing they have both .pem keys. The team members are trusted and within a single organisation.

My question is: What is the best way for us to manage and distribute the .pem files within the team so that:

  1. Team members can find the correct .pem files for the environment they wish to connect to
  2. The storage of the .pem files is secure
  3. We can explicitly authorise individual users to access the keys

Any suggestions most welcome.

Rob Lockwood-Blake
  • 203
  • 1
  • 2
  • 6
  • 1
    You may like to take a look at OpsWorks, it enables you to allow users to manage their own keys while you can manage which instances they have access to. http://docs.aws.amazon.com/opsworks/latest/userguide/opsworks-security-users.html – thexacre Jun 10 '15 at 03:52
  • Thanks for the heads up on Opsworks. We are using that to provision our stacks, so that makes things much easier for us. – Rob Lockwood-Blake Jun 10 '15 at 09:27

1 Answers1

31

You should not be sharing these keys. Period.

Each user should generate their own SSH keypair and their public key should be deployed to each system they need access to. Private keys are named as they are for a reason - they should be private to each user, generated by them, protected with a passphrase, and kept in a secure location on that user's workstation. Even with a fully-trusted team, using shared credentials goes against every best practice out there (for a variety of reasons).

When you start using per-user keys, both of your other issues go away.

Additionally, to avoid the stupid dual-ssh rigamarole, just put the following in your users ssh config:

Host internal-host.example.com 
  Hostname internal-host.example.com 
  User ubuntu
  IdentityFile ~/.ssh/id_rsa
  ProxyCommand ssh bastion-host.example.com nc %h %p 2> /dev/null

After doing this, your users will be able to run a single command to connect directly to the internal host, e.g. $ ssh internal-host.example.com.

EEAA
  • 108,414
  • 18
  • 172
  • 242