SSH Config Files

This article was published 8 years ago. Due to the rapidly evolving world of technology, some concepts may no longer be applicable.

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.


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
    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

Which gets translated to

$ ssh -i ~/.ssh/aws-eu-april2012.pem [email protected].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 [email protected]$1

Thoughts on this post

Alice Kaerast 2012-04-19

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.

mheap 2012-04-20

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.

psychic 2013-11-06

Thanks! Short and nice tutorial.

Small typos – The function name should be aws_login right ?

michael 2013-11-06

It should indeed! Fixed, thanks :)

sdcoca 2014-06-18

Nice. After a quick read to the man pages you quoted I found out that the Host field accepts patterns and they are matched against the hostname provided in the command line.

Hence, a config file just as below had the same effect any time I try too ssh any amazon AWS machine:

Host *
IdentityFile ~/my-key-pair.pem

nicolasdanelon 2016-08-25


Leave a comment?