Simplify Your Life With an SSH Config File

If you're anything like me, you probably log in and out of a half dozen remote servers (or these days, local virtual machines) on a daily basis. And if you're even more like me, you have trouble remembering all of the various usernames, remote addresses and command line options for things like specifying a non-standard connection port or forwarding local ports to the remote machine.

Shell Aliases

Let's say that you have a remote server named dev.example.com, which has not been set up with public/private keys for password-less logins. The username to the remote account is fooey, and to reduce the number of scripted login attempts, you've decided to change the default SSH port to 2200 from the normal default of 22. This means that a typical command would look like:

$ ssh paulmicheli@dev.example.com -p 22000 password: ************* 

Not too bad.

We can make things simpler and more secure by using a public/private key pair; I highly recommend using ssh-copy-id for moving your public keys around. It will save you quite a few folder/file permission headaches.

$ ssh paulmicheli@dev.example.com -p 22000 

Assuming your keys are properly setup…

Now this doesn't seem all that bad. To cut down on the verbosity you could create a simple alias in your shell as well:

$ alias dev='ssh paulmicheli@dev.example.com -p 22000' $ dev # To connect 

This works surprisingly well: Every new server you need to connect to, just add an alias to your .bashrc (or .zshrc if you hang with the cool kids), and voilà.

~/.ssh/config

However, there's a much more elegant and flexible solution to this problem. Enter the SSH config file:

# contents of $HOME/.ssh/config Host dev HostName dev.example.com Port 22000 User paulmicheli 

This means that I can simply $ ssh dev, and the options will be read from the configuration file. Easy peasy. Let's see what else we can do with just a few simple configuration directives.

Personally, I use quite a few public/private keypairs for the various servers and services that I use, to ensure that in the event of having one of my keys compromised the damage is as restricted as possible. For example, I have a key that I use uniquely for my Github account. Let's set it up so that that particular private key is used for all my github-related operations:

Host dev HostName dev.example.com Port 22000 User paulmicheli Host github.com IdentityFile ~/.ssh/github_ecdsa Host prod.ssh.hostingservice.com user user.prod IdentityFile ~/.ssh/hosting_service_rsa Host dev.ssh.hostingservice.com user user.dev IdentityFile ~/.ssh/hosting_service_rsa 

The use of IdentityFile allows me to specify exactly which private key I wish to use for authentification with the given host. You can, of course, simply specify this as a command line option for "normal" connections:

$ ssh -i ~/.ssh/blah.key username@host.com 

but the use of a config file with IdentityFile is pretty much your only option if you want to specify which identity to use for any git commands. This also opens up the very interesting concept of further segmenting your github keys on something like a per-project or per-organization basis:

Host github-project1 User git HostName github.com IdentityFile ~/.ssh/github.project1.key Host github-org User git HostName github.com IdentityFile ~/.ssh/github_ecdsa Host github.com User git IdentityFile ~/.ssh/github.key 

Which means that if I want to clone a repository using my organization credentials, I would use the following:

$ git clone git@github-org:orgname/some_repository.git