In my daily work, I meet many developers who don’t know much about Secure Shell (SSH). I totally get it – there are so many other things to learn that getting down to configuring SSH is usually very low on the list of priorities. As a result, some developers fall behind. That’s why I decided to finally write this short SSH tutorial, because there is a lot to gain for very little time invested.

I’m going to over some SHH best practices and various ways of making your experience with SSH much more pleasant and efficient. I’m going to start from giving some basic overview of the SSH protocol (e.g. private key pair and public key pair, or SSH connection) as well as some other encryption methods in the context of SSH, and then introduce:

• a way to connect to all instances with just one configuration file,
• an easy method of accessing multiple instances with multiple configuration files,
• a handy way of providing autocompletion for SSH names.

Without further ado, let’s improve your experience with SSH!

SSH tutorial – introduction to encryption methods

A common situation in the development process is the need to connect to many instances via SSH.

Unfortunately, many projects (especially the long-running ones) don’t have CI/CD or other safe solutions for managing accesses. It takes time to prepare them.

I’m not here to blame people for that. It happens and we have to deal with it.

Befowe we get to the main part of the tutorial, a quick overview of SSH:

Basics of SSH and encryption – public key & private key

The SSH protocol has been in constant use since in 1995 and provides a relatively safe (compared to, say, telnet) method of connecting to a remote server using encryption(instance of a remote machine). The security is ensured by various methods of encryption to open the SSH connection. The RSA (Rivest–Shamir–Adleman) encryption is one of the most popular methods. Unfortunately, it is not quite as secure as it used to be. Another encryption method I can recommend is the ed25519 method. Interestingly enough, this far shorter key is significantly more secure than RSA.

Using SSH, key pairs and the ed25519 method

Unfortunately, the ed25519 method has its limits. For example, the AWS server doesn’t permit the use of a SSH key pair other than the RSA by default. Only once you create an instance, you can make an SSH connection (SSH to the server), add a new public key and encrypt it by using the ed25519 method.

For your convenience, the command to add the public key from the local level:

ssh-copy-id -o ConnectTimeout=10 -f -i <path_to_public_key> <host_name>

It’s also vital not to use one SSH private key everywhere. If the private key leaks, the attacker will potentially be able to do a lot of harm. In this article I’ll show you a few really useful tricks, including how to make sure that you don’t need to remember the paths to your private key if you do decide to make more of them.

With that said, we get to the most important part of this SSH tutorial – making your everyday work with the protocol easier. Let’s get right to it!

1. One configuration file to rule (or manage) them all

In my career, I’ve seen so many developers who had files with tips on “how to connect to the instance”. They always included some copy-paste content for use in the terminal. I was also this type of person for quite a long time. 🙂

Finally, one of the DevOps engineers gave me a solution for that problem.

By default, SSH reads config from the ~/.ssh/config file. When you put your configurations there, you will be able to use ssh <host> to ssh to the instances. No more special files with tips required here!

And now just type ssh server_1 in the terminal to connect to the instance and you are all set!

2. Access many instances with multiple configuration files

There are a lot of projects that have hundreds of instances. Sometimes, one person works on many different things simultaneously. It has the potential to create a new problem – the configuration file keeps growing in a way that is very difficult to control.

There is a solution to this. We can split the ~/.ssh/config file into a couple of smaller files by project/environment/whatever you want.

However, this creates another challenge – SSH doesn’t know the new paths to config files. 

Luckily, it’s easy to fix. Just add Include ~/.ssh/configs/*/config to ~/.ssh/config. Now SSH will look for config files in every directory inside ~/.ssh/configs. 

The final directory structure:

3. Autocompletion for SSH

Writing and remembering manual names for connecting via SSH is not the best practice – there is no doubt about it. I also don’t recommend looking at each configuration file to find the correct name to connect.

To solve this problem, it’s necessary to provide autocompletion for SSH names. It should show the current list of hosts and prompt names like “ls” or other Linux commands.

Some OSes don’t have an easy way to add their own scripts for autocompletion. In order to fix it, I recommend checking the bash-completion repository. MacOS users can use the `brew install bash-completion` command.

Since Ubuntu has this option by default, we can simply modify the /etc/bash_completion.d/ssh file by adding the following code:

I won’t lie. I found this script in a related StackOverflow question (thank you, author!). I modified it to work with the new structure that was created in previous steps. The difference is in the host path and the “R” flag for the “grep” command.

With this script, we can write ssh <tab>. The terminal will show suggestions with possible hosts to connect to.

Note: It might require reloading the source ~/.bashrc bash source file for Ubuntu or reload .bash_profile for macOS. Then, the new terminal window should load the SSH autocomplete script.

SSH tutorial – summary

Secure Shell – not as scary as one might think!

As you can see, with just a few lines of code, you can make your life much easier. SSH has lots of features to make your work with public key and private key, SSH server and SSH clients much easier, with the ability to manage all connections from one file SSH config, key pair improvements and much more.

Best practices of SSH use

I highly recommend you read more about Secure Shell and how it works. It’s crucial from a security point of view to follow SSH best practices, connection guidelines and such to secure both the local machine and the entire system. Unfortunately, as it is currently the case, those SSH best practices are rarely part of everyday practice. Change it in your code and organization!