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:
- First, make sure you have boto installed and configured:
- sudo pip install boto
- Configure your ~/.boto file(s).
- Next, wget my gist or copy-paste the code embedded below into a file.
- Run the script and pipe output to a named SSH configuration file:
-
python generate_aws_ssh_config.py > ~/.ssh/bcllc_config
-
- 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.
- Next, we’re going to create an alias for ssh in your ~/.bashrc:
-
alias vssh='ssh -F $VSSH_CONFIG'
-
- 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:
