Streamline your SSH Workflow with .ssh/config

If you're a sysadmin, or find your self working with a number of different SSH hosts on a day to day basis you are probably use to just putting up with the annoyances that come along with structuring your SSH commands when logging into hosts.

Non-standard Usernames

I personally work with a variety of different systems that aren't all setup the same way, or have requirements that mean that my authentication to the box is not as simple as ssh root@ipaddress.

With the introduction of AWS EC2 Linux 2 images, came a new username that I had to prepare my ssh commands for, and when I had a mix of Debian and Ubuntu images each with non-standard usernames it was always a pain to remember which box needed what?

Private Keys Everywhere

$ ls -al | grep pem
-r--------@   1 nathan  staff   1696 Aug 10 11:09 aws-home.pem
-r--------@   1 nathan  staff   1696 Aug  3 14:50 aws-work.pem
-r--------@   1 nathan  staff   1692 Aug 21 21:24 svr-home.pem
-r--------@   1 nathan  staff   1696 Jan  3 11:04 svr-work.pem

Its not just usernames that need to be remembered; If you have any reasonable sense of security you or your company probably have SSH keys that you need loaded onto your system that you use to authenticate with your desired server.

Overtime you just accumulate keys from all over, and it becomes a game of Find the key that works until you eventually just become frustrated and put security aside as you just use the same key-pair on every server.

There are totally some readers who might have companies who manage their key stores for them, and deploy a single key per system that has its effective permissions tied to the employees role, and while that approach is totally valid, its not always possible for everyone situation.

Introducing .ssh/config

The config file with the .ssh folder in your users home path solves most if not all of our common issues; and I've found that it either not known about or very underused by IT professionals and Developers.

Basic Config

The most simple configuration that I will typically see, or setup on systems is the following

Host *
  AddKeysToAgent yes
  IdentityFile ~/.ssh/id_rsa

This configuration defines the following:

1. Host *: This config should be applied to all SSH connections.
2. AddKeysToAgent: When the SSH agent prompts for the use of the key, it should load and remember it until the daemon either restarts or the system reboots (removes the need for typing your password in 100 times a day)
3. IdentityFile: Your primary private key is named id_rsa and resides in the HOME/.ssh path of a users system.

For the most part this configuration will be fine for most users, and perfect for people who have just a simple private key that they use for things like authenticating with GitHub / version control over SSH.

Advanced Config

Lets look at a more advanced example. Say we have the following servers, key-pairs and usernames:

We have a lot of complexity that we need to account for, and you can already start to imagine how annoying it would be to have to enter each of those commands from memory each time. The great thing is, we can reduce all the guessing and complexity down to a configuration shown below in our .ssh/config

### Global ###

Host *
  AddKeysToAgent yes
  IdentityFile ~/.ssh/id_rsa

### Work ###

Host 11.150.20.3
User ubuntu
  IdentityFile ~/.ssh/aws-work.pem

Host 14.222.10.23
User nathan
  IdentityFile ~/.ssh/srv-work.pem

### Home ###

Host 13.124.22.54
User ec2-user
  IdentityFile ~/.ssh/aws-home.pem

Host 15.31.2.1 devopstar.com
User root
  IdentityFile ~/.ssh/srv-home.pem

This has the amazing effect allowing us to simply ssh to the given hostname or IP address and all the key-pair configuration and username selection is handled by referring to the file.

You might have also noted that cases where we have a domain resolving along with an IP address, we can provide multiple Host identifiers in both the IP and DNS form have cover both.

--- Featured Photo by Chunlea on Unsplash