SSH Config Files

Since I started working with Amazon AWS, I’ve been juggling a million and one different SSH keys. One set for live, one for staging, one with access to only certain servers. Trying to remember which Amazon DNS record pointed to which server was hard enough, nevermind which keys go with which servers. Fortunately, I only tried to do this for 15 minutes or so before Google came to my rescue and educated me about SSH config files.

Config Files

SSH config files are awesome. You define all of your connections once and then log into the desired server by typing:

$ ssh alias_chosen

There are lots of different options available for use in the file, but the main ones that you’re likely to use are:

  • HostName
  • User
  • IdentityFile
  • Port

These settings can be placed in /etc/sshd_config if you want them to apply to all users, or in ~/.ssh/config if you want to set them only for the current user.You can find a complete list of available options on the ssh_config man page.

Example

The format of the file is very simple, it’s just a set of space delimited options in a plain text file. Indentation under each host field isn’t significant, but it just makes things a little easier to read. For example:

Host live_frontend
    HostName aws.amazon.255-255-255-255.dns.stupidlylong.domain.amazon.com
    User ubuntu
    IdentityFile ~/.ssh/aws-eu-april2012.pem 

Now if we want to login to the live frontend server, all we need to type is

$ ssh live_frontend

… and we’re in! If you’re using oh-my-zsh, you could even type ssh live then enter and it’ll autocomplete for you.

The problem with AWS and SSH

There is however, one huge issue that I have with Amazon AWS and SSH. If you have an instance that you only use occasionally, every time you spin it up you need to edit your SSH config file to contain the new HostName. I eventually got frustrated enough with this that I added a function to my .profile that takes a hostname as an argument and sets all additional options that are required. e.g.

$ aws_login aws.amazon.255-255-255-255.dns.stupidlylong.domain.amazon.com

Which gets translated to

$ ssh -i ~/.ssh/aws-eu-april2012.pem ubuntu@aws.amazon.255-255-255-255.dns.stupidlylong.domain.amazon.com

The function that I use can be found below. Add it to your .(bash|zsh”)rc file and start using it today

function aws_login(){
    ssh -i ~/.ssh/aws-eu-april2012.pem ubuntu@$1
}

Also read...

Comments

  1. What are you actually doing when you are have SSHed into these servers?  If you’re starting to get a large number of Amazon Cloud servers then maybe you should be automating and abstracting the processes you are doing via ssh.

    Reply
    • Generally pulling the latest version of a repo and restarting any scripts that have been updated. Sometimes tailing logs if we send out a large batch of invites. 

      I’m looking at getting a deployment system set up, but can’t decide between Phing and Capistrano. I know PHP much better than I know Ruby, but Capistrano looks so much nicer.

      That’s on the back-backburner though, as if I ever get a free minute I’m working on building up some Puppet configs. Though there’s not much time left to do any of the support work once all the app development’s been done.

      Reply

Leave a Reply