Home Secure Shell (SSH) How To Configure SSH Key-based Authentication In Linux

How To Configure SSH Key-based Authentication In Linux

By sk
Published: Last Updated on 6.3K views

This guide explains what is SSH key-based authentication, types of SSH authentication methods, and finally how to configure SSH key-based authentication in Linux and Unix-like operating systems.

What is SSH Key-based authentication?

As we all know, Secure Shell, shortly SSH, is the cryptographic network protocol that allows you to securely communicate/access a remote system over unsecured network, for example Internet.

Whenever you send a data over an unsecured network using SSH, the data will be automatically encrypted in the source system, and decrypted in the destination side.

SSH provides four authentication methods namely password-based authenticationkey-based authentication, Host-based authentication, and Keyboard authentication.

The most commonly used authentication methods are password-based and key-based authentication.

In password-based authentication, all you need is the password of the remote system's user. If you know the password of remote user, you can access the respective system using "ssh user@remote-system-name" command.

On the other hand, in key-based authentication, you need to generate SSH key pairs and upload the SSH public key to the remote system in order to communicate it via SSH.

Each SSH key pair consists of a private key and public key. The private key should be kept within the client system, and the public key should be uploaded to the remote systems. You should not disclose the private key to anyone.

Hope you got the basic idea about SSH and its authentication methods. Now let us configure SSH key-based authentication in Linux.

Configure SSH key-based authentication in Linux

For the purpose of this guide, I will be using Arch Linux system as local system and Ubuntu 18.04 LTS as remote system.

Local system details:

  • OS : Arch Linux Desktop
  • IP address : /24

Remote system details:

  • OS : Ubuntu 18.04 LTS Server
  • IP address :

Generate SSH key pair

As stated already, in SSH key-based authentication method, the public key should be uploaded to the remote system that you want to access via SSH.

The public keys will usually be stored in a file called ~/.ssh/authorized_keys in the remote SSH systems.

Important note: Do not generate key pairs as root, as only root would be able to use those keys. Create key pairs as normal user.

Now, let us create the SSH key pair in the local system. To do so, run the following command in your local client system.

$ ssh-keygen

The above command will create 2048 bit RSA key pair. Enter the passphrase twice. More importantly, remember your passphrase. You'll need it later.

Sample output:

Generating public/private rsa key pair.
Enter file in which to save the key (/home/sk/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/sk/.ssh/id_rsa.
Your public key has been saved in /home/sk/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:wYOgvdkBgMFydTMCUI3qZaUxvjs+p2287Tn4uaZ5KyE sk@sk
The key's randomart image is:
+---[RSA 2048]----+
|+=+*= + |
|o.o=.* = |
|.oo * o + |
|. = + . o |
|. o + . S |
| . E . |
| + o |
| +.*o+o |
| .o*=OO+ |

In case you have already created the key pair, you will see the following message. Just type "y" to overwrite the existing key .

/home/username/.ssh/id_rsa already exists.
Overwrite (y/n)?


Please be mindful that passphrase is optional. If you give one, you'll be asked to enter the password every time when you try to SSH into a remote system unless you are using any SSH agent to store the password.

If you don't want passphrase (not safe though), simply press ENTER key twice when you are asked to provide the passphrase. However, I recommend you to use passphrase.

Using a password-less ssh key is generally not a good idea from a security point of view. They should be limited to very specific cases such as services having to access a remote system without the user intervention (e.g. remote backups with rsync, unison, …).

If you already have a ssh key without a passphrase in private file ~/.ssh/id_rsa and wanted to update key with passphrase, use the following command:

$ ssh-keygen -p -f ~/.ssh/id_rsa

Sample output:

Enter new passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved with the new passphrase.

Copy SSH public key to remote systems

We have created the key pair in the local system. Next, copy the SSH public key to your remote SSH server using command:

$ ssh-copy-id sk@

Here, I will be copying the local (Arch Linux) system's public key to the remote system (Ubuntu 18.04 LTS in my case).

Technically speaking, the above command will copy the contents of local system's ~/.ssh/id_rsa.pub key into remote system's ~/.ssh/authorized_keys file. Clear? Good.

Type yes to continue connecting to your remote SSH server and then enter the sudo (or root user's) password of the remote system.

/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
sk@'s password:

Number of key(s) added: 1

Now try logging into the machine, with: "ssh 'sk@'"
and check to make sure that only the key(s) you wanted were added.

If you have already copied the key, but want to update the key with new passphrase, use -f option to overwrite the existing key like below.

$ ssh-copy-id -f sk@

We have successfully added the local system's SSH public key to the remote system.

We can now completely disable the password-based authentication in the remote system. Because, we already configured key-based authentication, so we don't need password-base authentication anymore.

Disable SSH Password-based authentication in remote system

You need to perform the following commands as root or sudo user.

To disable password-based authentication, go to your remote system's console and edit /etc/ssh/sshd_config configuration file using any editor:

$ sudo vi /etc/ssh/sshd_config

Find the following line. Uncomment it and set it's value as no.

PasswordAuthentication no

Restart ssh service to take effect the changes.

$ sudo systemctl restart sshd

Access Remote system from local system

Go to your local system and SSH into your remote server using command:

$ ssh sk@

Enter the passphrase to login to the remote system.

Sample output:

Enter passphrase for key '/home/sk/.ssh/id_rsa': 
Last login: Mon Jul 9 09:59:51 2018 from

As you noticed, we have logged-in to the remote system's account using passphrase which we created earlier using ssh-keygen command, not using the user account's actual password.

If you try to ssh from another client system, you will get this error message. Say for example, I tried to SSH into my Ubuntu system from my CentOS using command:

$ ssh sk@

Sample output:

The authenticity of host ' (' can't be established.
ECDSA key fingerprint is 67:fc:69:b7:d4:4d:fd:6e:38:44:a8:2f:08:ed:f4:21.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '' (ECDSA) to the list of known hosts.
Permission denied (publickey).

As you see in the above output, I was not allowed to SSH into my remote Ubuntu 18.04 systems from other systems.

Adding more client system's keys to SSH server

This is very important. Like I said already, you can't access the remote system via SSH, except the one you configured (in our case, it's Ubuntu).

I want to give permissions to more clients to access the remote SSH server. What should I do? Simple. You need to generate the SSH key pair in all your client systems and copy the ssh public key manually to the remote server that you want to access via SSH.

To create SSH key pair on your client systems, run:

$ ssh-keygen

Enter the passphrase twice. After the key pair is generated, copy the public ssh key (not private key) to your remote server manually.

Display the pub key using command:

$ cat ~/.ssh/id_rsa.pub

You should see an output something like below.

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCt3a9tIeK5rPx9p74/KjEVXa6/OODyRp0QLS/sLp8W6iTxFL+UgALZlupVNgFjvRR5luJ9dLHWwc+d4umavAWz708e6Na9ftEPQtC28rTFsHwmyLKvLkzcGkC5+A0NdbiDZLaK3K3wgq1jzYYKT5k+IaNS6vtrx5LDObcPNPEBDt4vTixQ7GZHrDUUk5586IKeFfwMCWguHveTN7ykmo2EyL2rV7TmYq+eY2ZqqcsoK0fzXMK7iifGXVmuqTkAmZLGZK8a3bPb6VZd7KFum3Ezbu4BXZGp7FVhnOMgau2kYeOH/ItKPzpCAn+dg3NAAziCCxnII9b4nSSGz3mMY4Y7 ostechnix@centosserver

Copy the entire contents (via USB drive or any medium) and go to your remote server's console. Create a directory called ssh in the home directory as shown below.

$ mkdir -p ~/.ssh

Next, append the your client system's pub key which you generated in the previous step in a file called "~/.ssh/authorized_keys":

echo {Your_public_key_contents_here} >> ~/.ssh/authorized_keys

Restart ssh service on the remote system. Now, you'll be able to SSH to your server from the new client.

If manually adding ssh pubkey seems difficult, enable password-based authentication temporarily in the remote system and copy the key using "ssh-copy-id" command from your local system and finally disable the password-based authentication.

Related Read:


SSH Key-based authentication provides an extra layer protection from brute-force attacks. As you can see, configuring key-based authentication is not that difficult either. It is one of the recommended method to keep your Linux servers safe and secure.

You May Also Like


chunkking714 February 2, 2017 - 9:04 pm

“You shouldn’t not disclose the private key to anyone.” Uh, bit a of a typo, there.

SK February 3, 2017 - 6:31 am

Sorry about the typo. Fixed now. Thanks for pointing it out.

Kranti December 8, 2018 - 9:47 am

Thanks for an extremely nice tutorial


Leave a Comment

* By using this form you agree with the storage and handling of your data by this website.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

This website uses cookies to improve your experience. By using this site, we will assume that you're OK with it. Accept Read More