How I setup SSH config for effectively managing multiple servers

Introduction

Secure Shell, or SSH, is the Swiss Army knife of remote server management. It allows you to connect to your servers securely over an encrypted connection, making it a must-have tool for any system administrator or developer.

In this guide, we’ll explore how you can effectively harness the power of SSH configuration to simplify the management of multiple servers.

The SSH Config File

At the heart of this process lies the SSH config file, typically found at ~/.ssh/config.

This file is a game-changer when it comes to managing multiple servers. It lets you define custom configurations for each server you connect to, eliminating the need to remember various login credentials and connection details.

Let’s take a look at an example of how I structure my SSH config file.

I have three servers that I connect to regularly. I have named them sukuna, nanami, and suguru. If you are wondering what are those names, the servers are named after characters from Jujutsu Kaisen ↗️ anime.

# Global options apply to all hosts unless overridden
Host *
  # Default user and identity file
  User akash
  Preferredauthentications publickey # Use public key authentication
  IdentityFile ~/.ssh/default-key

# Configuration for Sukuna
Host sukuna
  HostName sukuna.local
  Port 2222
  IdentityFile ~/.ssh/sukuna-key

# Configuration for Nanami
Host nanami
  HostName nanami.local
  Port 2200
  IdentityFile ~/.ssh/nanami-key

# Configuration for Suguru
Host suguru
  HostName suguru.local
  Port 2220
  IdentityFile ~/.ssh/suguru-key

Now to connect to any server (let’s say sukuna), all I have to do is run the following command

ssh sukuna

See how easy it is now. Let’s break down the above configuration to understand how it works.

• The first section is the global configuration. This section applies to all hosts unless overridden by a specific host configuration.

  Here, I have set the default user to akash and the default identity file to ~/.ssh/default-key.

• The next sections defines the configuration for each host. The Host keyword is followed by the name of the host.

  This name can be anything you want. I have chosen to name my hosts after famous scientists.

• The HostName keyword is followed by the IP address or domain name of the host.

  I have picked a domain name since I map the local IP addresses of my devices to a domain name using the Adguard DNS rewrites.

• The Port keyword is followed by the port number of the host.

  This is optional and only required if you are using a non-standard port for SSH (which you should if you have followed the guide I shared earlier about securing SSH).

• The IdentityFile keyword is followed by the path to the private key file for the host.

  This again is optional but I would highly suggest that you connect to your servers using public key authentication instead of passwords.

• The Preferredauthentications keyword complements the above option which specifies the order in which authentication methods are used.

  Here, I have set it to publickey which means that SSH will first try to authenticate using the public key and then fall back to password authentication if that fails.

Why This Configuration Is Ideal

This configuration follows best practices for an SSH config file. Here’s why:

• Global Settings: We’ve set a default user and identity file globally to avoid redundancy. This reduces the need to repeat the same settings for each host.

• Host-Specific Settings: Each host has its own section with hostname, port, and identity file settings. This keeps configurations organized and allows for easy customization for each server.

• Clear Naming: Host names like “sukuna”, “nanami”, etc., are clear and easy to remember instead of remembering IP addresses, making your SSH commands more intuitive.

• Uses Public Key Authentication: We’ve set the Preferredauthentications option to publickey which means that SSH will first try to authenticate using the public key and then fall back to password authentication if that fails. This is a more secure way of connecting to your servers.

• Uses different SSH ports and public keys: Each host has its own SSH port and public key. This is a good security practice as it makes it harder for attackers to guess your SSH credentials.

  A best practice is to use different key pairs for each server. Why? Imagine if your single key pair were compromised. An attacker would gain access to all your servers. By using distinct key pairs, you limit the scope of a security breach. If one key is compromised, only the corresponding server is at risk.

Final Thoughts

By following these best practices and crafting a well-structured SSH config file, you’ll streamline your server management and enhance your overall SSH experience.

With this setup, connecting to your servers is as simple as typing ssh Host. Plus, it ensures that you maintain a secure and organized approach to managing multiple servers efficiently.