Streamline your SSH Workflow with .ssh/config
Tags: ssh, tutorial, productivity, beginners
Published: 2020-02-19 14:03:14

---
title: Streamline your SSH Workflow with .ssh/config
published: true
description: Reduce security and operational complexity by managing your SSH key-pairs, usernames and hosts in the config file within your home SSH directory.
canonical_url: https://devopstar.com/2019/01/04/streamline-your-ssh-workflow-with-ssh-config
cover_image: https://dev-to-uploads.s3.amazonaws.com/i/w00ttmvgzj58bffkg08n.jpg
tags: ssh, tutorial, productivity, beginners
---

*This post was originally written on [DevOpStar](https://devopstar.com/)*. Check it out [here](https://devopstar.com/2019/01/04/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](https://aws.amazon.com/amazon-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

```bash
$ 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

```bash
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](https://help.github.com/articles/connecting-to-github-with-ssh/) / version control over SSH.

##### Advanced Config

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

| Entry                  | User                       | Key                                   |
|------------------------|----------------------------|---------------------------------------|
| 13.124.22.54           | ec2-user                   | aws-home.pem                          |
| 11.150.20.3            | ubuntu                     | aws-work.pem                          |
| 15.31.2.1              | root                       | srv-home.pem                          |
| devopstar.com          |                            |                                       |
| 14.222.10.23           | nathan                     | srv-work.pem                          |

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

```bash
### 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.

---

### Summary

---

Do you have some productivity hacks around SSH? I'm very interested in hearing about it! please reach out to me on [Twitter @nathangloverAUS](https://twitter.com/nathangloverAUS) and start a discussion.