How to use SSH Key..!!!

Creating SSH Keys

On your Mac or Linux machine, open Terminal.

Note: If you are using a Windows OS to SSH into a server, you will need to download third-party software as Windows does not allow SSH by default.

Verify that you have a .ssh folder in your $HOME directory. If the folder does not exist, create it:

$ mkdir ~/.ssh

Change your working directory to the .ssh directory and use the following command to generate an ED25519 SSH key pair:

$ ssh-keygen -t ed25519 -a 256

The “-t” in this command tells your computer what encryption type to use for the SSH key. If you would like to use a different encryption type, replace the “ed25519” with whichever encryption you choose.

Note: If you would like to store an SSH key in the OVHcloud Manager, you will only be able to use ED25519, RSA, or ECDSA encryption.

You will be prompted to enter a passphrase to password-protect your SSH key. This is entirely optional but recommended for added security. Your SSH keys will be created and stored in the .ssh directory. In order to read your public key, use the following command and copy the output:

$ cat ~/.ssh/

Now that you have created your SSH key pair, use the next section to tell your server that it can authenticate the public key you have just created.

Adding SSH Keys to Your Server

Navigate to your $HOME directory and look for a .ssh. If one does not already exist, create it by entering the following:

$ mkdir ~/.ssh

Create a folder to store your authorized keys. To do this, open a file with the name authorized_keys in a text editor of your choice (we’ll use vim). Navigate to the .ssh directory that you just created and open the file in a text editor of your choice with the following command:

$ sudo vi ~/.ssh/authorized_keys

Copy and paste the public key which you created in the previous section into this new text file. Save the file and exit the text editor. Restart your server or restart OpenSSH using the following command:

$ sudo systemctl restart sshd

To test that your key has been set up properly, attempt to access your server via SSH using the following command, remembering to replace “IP_ADDRESSorHOSTNAME” with the IP address or hostname of the server you are trying to access:

$ ssh [email protected]_ADDRESSorHOSTNAME

Adding Additional Authorized Keys to Your Server

To add additional authorized SSH keys for additional users, follow this article again using the new user’s $HOME directory to create that user’s unique key.

Removing Authorized Keys from Your Server

Remove the key which corresponds to that user from your authorized_keys file. Upon removing the key, save the file and exit the text editor.


SSH key pairs are important to ensuring the security of your server. While the steps you took using this article should be sufficient for most use cases, it is worth noting that OpenSSH can be configured to be more secure if that extra security is needed. Regardless of what your security needs are, they are too important to not use the strong layer of security which SSH keys provide to you.

How to Secure you SSH Connection in Ubuntu 18.4

Creating a New Sudo User

It is always best practice to disallow root authentication over SSH since this is the username people will try to hack into the most. Thus, the first thing we want to do to secure our server is create a new sudo user for SSH. To do so, enter the following command, replacing the red username with the username of your choice:

# adduser username

Follow the prompt to set a password and provide any other information you wish; only the password is required. Now, we want to give our new user sudo privileges so that we can become root and run commands which need administrative privileges. We can do this by entering the following command.

# usermod -aG sudo username

Last, we want to enable our new user to authenticate using the SSH public key we have already provided to the root user. We can use a simple rsync command to copy the public key over to our new user’s authorized_keys file.

# rsync --archive --chown=username:username ~/.ssh /home/username

Before proceeding to the next step, log out and make sure that you are able to authenticate to the server as the new user using SSH. If you are unable to login as your new user, you will still be able to log in as root; confirm all of the commands have been entered correctly and try to log in as your new user again.

Changing the SSH Daemon Configuration

Since we are using SSH keys and a new user to authenticate to our server, we do not ever want anyone to authenticate using a password or the root username. To accomplish this, we first want to navigate to the configuration file for the OpenSSH daemon. To do so, open the file in a text editor of your choice using the following command:

$ sudo vi /etc/ssh/sshd_config

There are three changes we want to make to this file.  First, we want to change the port on which OpenSSH listens for requests.

Warning: If you have any active firewalls, you will need to allow traffic through the port you choose or you will lock yourself out of your server. If you do lock yourself out of your server, you can regain access through IPMI or KVM.

At the top of the file, you will see a section that looks like this by default:

#Port 22
#AddressFamily any
#ListenAddress ::

Uncomment the “Port” section and choose any valid port number like in the following example. In our example, we use port 12345.

Port 12345
#AddressFamily any
#ListenAddress ::

Next scroll down to the # Authentication: portion of the file. You will see five options that will appear as follows by default:

#LoginGraceTime 2m
PermitRootLogin yes
#MaxAuthTries 6
#MaxSessions 10

Here we want to change the “yes” next to “PermitRootLogin” to “no.” It will appear as follows:

#LoginGraceTime 2m
PermitRootLogin no
#MaxAuthTries 6
#MaxSessions 10

Now we want to scroll down the sshd_config file a little further to make our final change – disabling password authentication. You will see a section that looks like this by default:

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes
#PermitEmptyPasswords no

We want to change the “yes” next to “PasswordAuthentication” to a “no.” It will appear as follows:

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
#PermitEmptyPasswords no

Save and exit the file. Finally, we need to restart OpenSSH for the changes to take effect. Do this by entering the following command:

sudo systemctl restart sshd.service

Let’s take a second to review what we did here. We changed the port number that we use to listen for SSH requests. Then, we disabled SSH access for the root user or any user trying to authenticate with a password. If we have done this correctly, the following command will no longer work to log in to the server.

$ ssh

To log in now, we are going to have to specify the port number we are using to listen for SSH requests. That means from now on we will need to use the following command, replacing the number next to “-p” with the port number we chose earlier:

$ ssh -p 12345

Make sure that this command works and that the previous one does not. If it does, you are all set to access your server securely through SSH.


With so many bad actors out there using the internet, it has never been more important to secure any potential entry points to your server. By following this guide, you have made the most common entry point on Linux servers much more secure.

We have launched our website!

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean commodo ligula eget dolor. Aenean massa. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec quam felis, ultricies nec, pellentesque eu, pretium quis, sem.

Nulla consequat massa quis enim. Donec pede justo, fringilla vel, aliquet nec, vulputate eget, arcu. In enim justo, rhoncus ut, imperdiet a, venenatis vitae, justo. Nullam dictum felis eu pede mollis pretium. Integer tincidunt. Cras dapibus. Vivamus elementum semper nisi. Aenean vulputate eleifend tellus. Aenean leo ligula, porttitor eu, consequat vitae, eleifend ac, enim.

Read more