OpenSSH – Configure Key Based Authentication

By default when installing OpenSSH it will be configured to accept a user name and password combination for authentication. To increase security you can enable key based authentication and disable password authentication so that when a user authenticates to the server over SSH it will require that key (and a decryption password for the key if the key was encrypted with a pass phrase) when users authenticate. I have written this article using a Ubuntu 16.04 server with a default install of OpenSSH but it should be the same, if not very similar for any other Debian based distribution.


Generate SSH Keys

Prior to configuring OpenSSH to use key based authentication you will want to generate a private/public key pair for your user so when you make the switch you can test it out right away. In this post I outline how to generate SSH private and public keys, make sure you do this prior to reconfiguring OpenSSH to use key based authentication.


Edit OpenSSH Configuration File

Once you have your private/public key pair generated for your user you will need to use a text editor (vi, nano, etc.) to edit the OpenSSH configuration file. The ssh configuration file is found at ‘/etc/ssh/sshd_config’. Prior to editing the configuration file you should back it up in case you make a mistake editing the file and can’t track it down you can just restore the previous version of the configuration file.

To backup the configuration file issue the command below

Now open the configuration file with your text editor, below is an example using nano. Note if your not logged in as root you will need to use ‘sudo’ to edit the file otherwise when you come to save the file it will not let you due to permission issues.

Look for the following 3 lines in the config file, to assist you in the search using nano as your text editor you can hit Ctrl+W to search for text.

Make sure the line with ‘AuthorizedKeysFile’ is uncommented and both the RSAAuthentication and PubkeyAuthentication lines are set to ‘yes’. One thing to understand about the ‘AuthorizedKeysFile’ line is the value after is the path the server should use to grab the public key, so in the above example it is configured that when a user authenticates it is looking inside of that users home directory in the .ssh folder inside of the ‘authorized_keys’ file for the public key it should use. It is important to understand this because when a user goes to authenticate if they do not have an authorized_keys file inside of a .ssh folder within their home directory they will not be able to authenticate to the system.


Next you will will want to search for the ‘PasswordAuthentication’ option. By default this is set to ‘yes’ which is telling the server to allow user to login with their username and password, we need to disable this to force key based authentication so change it to ‘no’

At this point we have made all of the changes we need to make and we can save our file and exit.


Implement Changes

If we were to test right after saving our file we would still be able to login with our username and password this is because we have not reloaded or restarted the SSH service causing it to operate under our latest changes in the configuration file. To reload the SSH service issue the following command.

It is safe to issue this command while logged in via SSH, your session will not be terminated.



Now if we are on our client computer and attempt to login without a key file we should get an error message similar to below.

This is good, we know we are being presented with our public key and the server is not letting us even attempt to authenticate without a private key.

Now lets pass the key to our server and attempt to login.

And we can see because I did not encrypt my key with a pass phrase (bad security practice) I was logged in and I am now presented with a prompt from my server.



We have confirmed that our changes are working as we expect, we do not need to keep our backup SSH configuration file on the server anymore, if you wish to back it up somewhere for historical purposes that is a good idea but at the end of the day we should remove it from our server so it doesn’t clutter up the configuration directory. Issue the command below to delete the backup configuration file



To recap we have configured OpenSSH Private and Public keys for our user to authenticate with, reconfigured our SSH server to use key based authentication and successfully tested authenticating without a key which failed as expected and with our key which succeeded as expected. One thing to keep in mind which I mentioned earlier from now on any new or existing user on the system that needs to login via SSH will need to have a public key in their profile and the user will need the corresponding private key to use for authentication otherwise they will not be able to login.

I hope this was able to help you out and if it was please share this post on social media!

Be the first to comment

Leave a Reply

Your email address will not be published.