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.
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?
$ 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.
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.
The most simple configuration that I will typically see, or setup on systems is the following
This configuration defines the following:
- Host *: This config should be applied to all SSH connections.
- 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)
- 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.
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 ###
### Work ###
### Home ###
Host 184.108.40.206 devopstar.com
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.