The most important parts of a setting up a secure server are often the simplest. However, to the uninitiated or less experienced, these details can often be overlooked. These gaps in knowledge are easily corrected when it becomes clear that there is a better way to do things. Such is the purpose of this guide in which we discuss SSH security.

What is SSH?

SSH is a simple protocol by which communication between two computers can be securely verified and the traffic exchanged is secured cryptographically. Use of encryption in online communications is particularly useful when dealing with situations where the material being exchanged is sensitive in nature. Given the need to ensure that your operation remains secure from outside threats, having a good understanding of this simple yet effective tool is a necessity. This guide walks you through setting up SSH effectively as part of setting up and securing your operation for communication through SSH.

What you will need

We will be using the OpenSSH implementation of SSH. On the machine that will be initiating the connection you will need to ensure the you have the openssh-client installed. On the machine to which you will be connecting, it is required that the openssh-server be installed.

sudo apt update
# For the client
sudo apt install openssh-client
# For the server
sudo apt install openssh-server

Keep in mind these packages may already be installed, specifically with virtual machines which must provide you with an option to connect to them remotely out of the box. Once you have these packages installed in the right places, you have everything you need to get started.

Windows client users will need to supplement information in this guide with another to ensure they have everything they need to get started on the client side. This guide appears to be a good place to start as SSH was recently built into Windows 10.

Initial Connections

Once the correct packages are installed the command format to reach any server is as follows.

# Basic command format: ssh <user>@<host>
ssh myusername@

A successful connection will often result in a password request (assuming one has been set) and a successful password entry then grants access to the CLI of the server to which you have connected. Boom! You are in and ready to work.

If you are unable to connect, this could point to a number of issues. The most common of which can be remedied by confirming you have entered a correct user@host location and ensuring that your firewall has not been set to block connections on port 22 which is the port on which SSH is configured to listen by default.

This is a good start, but we need to do a bit more to improve security further.

Changing The Default Port

Defaults are a great feature for any software. They provide a means to easily onboard new users, but at the same time these defaults can make it easier for a potential attacker to find and probe your system. In the initial setup above, we worked with the assumption that the default connection via SSH would take place over port 22. This same assumption is made every day by bad actors operating automated systems designed to probe at commonly exposed openings. SSH on port 22 being one such opening.

SSH probing by an unknown user (as taken from /etc/log/auth.log)

The above type of probing happens all the time, but it’s generally done blindly, as it’s far easier for an attacker to test the default than it is to guess which of the other 65534 ports on which SSH might currently be listening.

The configuration file which determines the port on which SSH listens by default is located in the /etc/ssh folder.

cd /etc/ssh/
sudo nano sshd_config

This file contains a number of useful configuration parameters which can be toggled to harden your SSH security policy. For now we’ll focus on adjusting the port location, which should be visible commented out with the default value.

#Port 22

To change the default, simply uncomment the line and change the port number. Then save an exit to commit the change to the file.

Port 2001

It is generally advisable to select a port on which no other services are known to be assigned to listen. You can refer to this Wikipedia page for a full list of port values, as well as the services on which certain ports are known to listen to by default. You’ll notice SSH at 22, as well as other common Internet protocols such as protocols such as HTTP at 80 and DNS at 53.

Once any change is made to the sshd_config file, for them to take effect, your SSH server must be restarted.

sudo systemctl restart ssh
sudo systemctl status ssh

The first command executes the restart. The second is entirely optional, but allows you to confirm the functional status of the SSH service so you can confirm it was restarted correctly.

Once you’ve made this change, make sure you remember the new port which you set for SSH to listen, as you will now need to specify this information explicitly to the command line when performing an SSH connection from your client machine.

ssh myusername@ -p 2001

The default argument set for the port number is (you guessed it) 22, so now that we are on port 2001, as per our example, then we must specify this new piece of information in order for our connection to succeed. This is done by specifying the port with -p.

SSH Keys

An SSH key is an additional layer of security tied the authentication process of a connection between a client and a server. It consists of generating a private-public key pair, which, once installed, is then used to securely establish connections between both systems, without the need for password prompting on the part of the server. Once in place the only systems that will be able to connect to the remote server are systems with valid SSH keys installed on them. As an additional layer of protection, passwords are set on these keys which the client requests from the user prior to being able to establish the connection with the server.

Security is improved as only someone in possession of a valid private key matching a public key installed on the server can gain access to it via SSH. This also means it is important to keep these keys safe and securely backed up, in case there is ever a need to use them with a different machine as the client.

The first step is to generate a private-public key pair with the below command.


Executing this command begins a series of prompts through which the key pair is generated.

First you are asked to name your key. By default it will be named id_rsa and will be placed in the ~/.ssh/ default location. It is advisable to pick a different name to avoid accidentally overwriting an existing pair of keys in the future. Then select a password you will remember, which you will be prompted to enter each time you want to use the key to connect to the remote server (unlocking your ability to use it).

The result should be a pair of keys with the name you specified located in the default folder where ssh keys are generally stored, located at ~/.ssh. Notice that one key has .pub at the end of it. This is your public key. The other file is your private key.

The next step is to now install your newly generated public key onto the server to which you will be connecting. To do this we will use the ssh-copy-id functionality built into OpenSSH.

ssh-copy-id -i ~/.ssh/ -p 2001 myusername@

The above command specifies the location of the keyfile via the -i argument. By default it is id_rsa. We also have to specify the port we want to use, as we’ve changed it from the default 22. You will be prompted for the remote server password prior to being able to establish the connection and transfer the public key file. Once the public key has been transferred, you will now be able to log in using your SSH key as follows.

ssh -p 2001 -i ~/ssh/serverxyz_rsa myusername@

You will then be prompted for the password specified when creating the key. This step authenticates on the client side, that you have the right to use the private key to establish a connection with the remote server, on which you’ve just installed the public key. This step can be circumvented for convenience by adding your private key to the ssh-agent as follows.

ssh-add ~/ssh/serverxyz_rsa

If the command is accepted, you will be prompted for your key password again, but now, so long as the agent remains active, you will no longer need to provide your password to establish future SSH connections with the key. If the above command failed, it’s possible that an SSH agent is not currently available. If this is the case, you can spin one up using the ssh-agent command and try the above command again.

Setting Up A Config File

This step isn’t necessary, but it wraps everything we’ve done so far together really nicely by adding a lot of convenience when it comes to managing many sets of credentials for connecting to many different servers. You can collect and store all your information in a config file that SSH then uses to allow you to connect via SSH using a shortened custom name for the connection you wish to establish. To do this, you will need to create a file named config under the ~/.ssh/ folder, if one doesn’t exist there already. 

cd ~/.ssh/
nano config

Here’s how the connection we’ve setup in the previous examples would look like as information stored in the config file.

Host serverxyz
        IdentityFile ~/.ssh/serverxyz_rsa
        User myusername
        Port 2001

You can have as many of these entries as you like inside your config file. Once setup you can establish the SSH connection using the custom name you provided in the config file under Host. In our case that would be serverxyz.

ssh serverxyz

And voila! You are now connected to your server using all of the customized settings we’ve setup in this guide, using a single custom keyword. It doesn’t get simpler than that.

It’s a beautiful thing when you can increase the security of your server setup while also making it easier to establish the connections when you need them.

Additional SSH Configuration Settings

Last, but certainly not least is the matter of additional security settings which you can configure in the sshd_config file which, as you’ll recall, is the same file we updated earlier when changing our default SSH port.

cd /etc/ssh/
sudo nano sshd_config

It’s recommended to disable password based logins as we do not require or use these anymore now that we are setup to authenticate with SSH keys.

AuthenticationMethods publickey
PubkeyAuthentication yes
PermitEmptyPasswords no
PasswordAuthentication no
PermitRootLogin without-password

You can find most of the above settings commented out throughout the file, you can uncomment these entries and set the appropriate values listed above. Remember that you will need to restart your ssh service for these changes to take effect.

sudo systemctl restart ssh
sudo systemctl status ssh

Keep in mind that this is by no means an exhaustive list of configuration settings which you can modify, but for the purposes of this guide, it’s a good place to start when setting up SSH for the first time. Additional research is recommended.

In Conclusion

You’ve now setup your server to operate securely using generated SSH keys, disabling password based access, and changed the port on which the SSH service is listening for traffic. You’ve also setup a config file that captures all these changes and allows you to use a custom name with the SSH command to establish your connections. By doing so you’ve improved the usability and security of your server setup. Well done!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>