As a consultant and advisor to many firms running on or investigating AWS, I find SSH host and key management to be a constant struggle.  From IAM credentials to default OS logins, it’s easy to lose time with constant lookups.  Over time, I’ve written a few tools that make it easier to quickly “chroot” or “virtualenv” your SSH environment.  Below is a small example of the logic and usage pattern that I’ve found to be very helpful:

1. First, make sure you have boto installed and configured:
   • sudo pip install boto
   • Configure your ~/.boto file(s).
2. Next, wget my gist or copy-paste the code embedded below into a file.
3. Run the script and pipe output to a named SSH configuration file:

   • python generate_aws_ssh_config.py > ~/.ssh/bcllc_config

4. At this point, you’ll have an SSH configuration file with the following details.  If any assumptions are incorrect, manually edit the file.
   • A host entry for all reservations; yes, even stopped ones!
   • The host entry name is pulled from the EC2 tag “Name” if exists, else instance ID.
   • The default SSH user is pulled from the EC2 tag “user” if exists, else set to default (e.g., ubuntu).
   • You do automatically tag your instances with variables when you provision them, right? . . .
   • The key/identity file is set to the ~/.ssh/{keypair-name}.pem.  Basically, if you save the keys as generated into your ~/.ssh/ folder, you should be fine.
5. Next, we’re going to create an alias for ssh in your ~/.bashrc:

   • alias vssh='ssh -F $VSSH_CONFIG'

6. When you want to switch between client sandboxes, you then simply export VSSH_CONFIG to the named config file and proceed:

   • export VSSH_CONFIG=~/.ssh/clientA_config

   • vssh web-tier-0

   • export VSSH_CONFIG=~/.ssh/clientB_config

   • vssh postgres-0

It’s easy to see how this logic can be extended into segregated virtualenv-style SSH environments, as well as aliases for `rdesktop` on Windows servers.

Happy shelling!  And, as promised, script embedded below: