Configure a Custom SSH Key Based Authentication In Linux – RHEL/CentOS 7&8

UNDERSTANDING THE SUBJECT MATTER

In Part 1 and part 2 of configuring and managing SSH in Linux, I already explained the meaning of SSH, how SSH works, how to connect to a Linux server via SSH, how to change the SSH default port, etc.

In this tutorial, I will show you the step by step process of how to configure a custom and non-custom SSH key-based authentication in Linux

What is SSH key Based authentication?

SSH key-based authentication is a method of authenticating to a remote server using SSH keys rather than the usual way of using a password.

Suggested Tutorial: Connecting To a Linux Server via SSH


How do I enable SSH key based authentication?

SSH key based authentication is not a feature that can be enabled. SSH keys, private and public pairs have to be generated before this authentication method can be configured and used.

The public key will encrypt while the private key will decrypt.

The pubic key will be copied to the remote server you want to authenticate with, into a file called (authorized_keys). It is these authorized keys that will authorize the connection between the two servers. See the “ACTION TIME” Section to see how it can be configured.

What is ACTION TIME section on TekNeed?

Suggested Tutorial: Understanding The Concept Of LVM

ACTION TIME

How do I configure SSH key based authentication on a Linux server?

The step by step process below will guide you on how to configure a custom SSH key-based authentication and a non-custom/default SSH key-based authentication.

1. Generate the ssh private/public key pairs

[root@DRDEV1 ~]# ssh-keygen

Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): 

NB: you can either choose a new file name or any location you wish to save the keys. However, it is not recommended you choose a new location. If you press the enter key, the keys will be saved to (/root/.ssh/id_rsa) by default as seen from the output of the command.

Note: if you are logged in as a different user, the keys will be saved in that same location by default, but in the user’s home directory (~/.ssh/id_rsa) , except you specify otherwise.

Since we are customizing our keys, we will choose a new file name in the same location which is (/root/.ssh/myid)

Enter file in which to save the key (/root/.ssh/id_rsa): /root/.ssh/myid

2. Press the enter key, and you will be prompted to enter a passphrase so you can secure the private key

Enter passphrase (empty for no passphrase):

Enter a passphrase for the public/private rsa keys that will be generated. (if you want to always login without a passphrase, do not enter a passphrase, just press enter).

In our case, we will use a passphrase.

Enter same passphrase again:
Your identification has been saved in /root/.ssh/myid.
Your public key has been saved in /root/.ssh/myid.pub.
The key fingerprint is:
SHA256:TmG9FkWTmntVEG2bPs5328XqBz8IebWlJBFkoFXLLMk root@DRDEV1
The key's randomart image is:
+---[RSA 3072]----+
|          o=Ooo+ |
|         = *oo  +|
|        + Eo+. oo|
|       . .o+. o+.|
|        S o..+o.o|
|       o ..o..o= |
|        .  .o +o+|
|             . =B|
|             .oo*|
+----[SHA256]-----+

From the display, you can see that the rsa keys have been generated, and the private key has been saved in (/root/.ssh/myid) and the public key saved in (/root/.ssh/myid.pub)

2. Verify that the rsa keys have been generated.

[root@DRDEV1 .ssh]# ls /root/.ssh/myid

/root/.ssh/myid /root/.ssh/myid.pub

3. copy the SSH (PUBLIC KEY) to the remote server

you can use the utility called “ssh-copy-id” to copy ssh keys

NB: if you don’t specify the SSH identity, i.e, the key you want to copy, according to the man page, by default, it will copy ( ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 and ~/.ssh/id_rsa) if it exists

ssh-copy-id -i /root/.ssh/myid.pub user@192.168.170.171
[root@DRDEV1 ~]# ssh-copy-id -i /root/.ssh/myid.pub 192.168.170.171

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/root/.ssh/myid.pub"
The authenticity of host '192.168.170.171 (192.168.170.171)' can't be established.
ECDSA key fingerprint is SHA256:Bgbw02qvsN9h0Bh9PR5bYNgtw6eLQ/KtUD357KXBiB0.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
/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
root@192.168.170.171's password:

Number of key(s) added: 1

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

The public key will be copied to an (authorized_keys) file on the remote server. The authorized_keys file is found is (~/.ssh/authorized_keys). Since we are root, the public key will be in (/root/.ssh/authorized_keys).

NB: If the file doesn’t exist, there has never been any ssh-key based authentication from such user. Hence, it will automatically be created, and the newest public key will always be in the last line of the file.

The (authorized_keys) file is used to store the public keys on the remote server.

4. Make a connection to the remote server – use the private key that was generated.

[root@DRDEV1 ~]# ssh -i /root/.ssh/myid 192.168.170.171

Enter passphrase for key '/root/.ssh/myid':
Activate the web console with: systemctl enable --now cockpit.socket

This system is not registered to Red Hat Insights. See https://cloud.redhat.com/
To register this system, run: insights-client --register

Last login: Thu Oct 22 18:44:14 2020 from 192.168.170.1
[root@server1 ~]#

Now we can successfully connect to the remote server. However, we will still need to input the passphrase before we can connect which means you are not still fully secured because just one nasty person might be able to guess your password, especially when you might still have to type it in their presence.

Suggested Article: A Few Basic Tips In Securing SSH Authentication In linux

What you could have done was not to input the passphrase in step 2, but still, you can make use of the ssh-agent process to save the passphrase. It will eradicate the use of a passphrase

5. Activate ssh-agent

[root@DRDEV1 ~]# ssh-agent $SHELL

OR

[root@DRDEV1 ~]# eval $(ssh-agent)

Agent pid 108089
[root@DRDEV1 ~]# ps aux |grep 108089

root     108089  0.0  0.0  29440   544 ?        Ss   21:58   0:00 ssh-agent
root     108128  0.0  0.0  12108  1072 pts/3    S+   21:58   0:00 grep --color=auto 108089
SSH key based authentication

6. Add the private key to the ssh-agent

[root@DRDEV1 ~]# ssh-add /root/.ssh/myid

Enter passphrase for /root/.ssh/myid:
Identity added: /root/.ssh/myid (root@DRDEV1)

7. Connect again

[root@DRDEV1 ~]# ssh -i /root/.ssh/myid 192.168.170.171

Activate the web console with: systemctl enable --now cockpit.socket

This system is not registered to Red Hat Insights. See https://cloud.redhat.com/
To register this system, run: insights-client --register

Last login: Thu Oct 22 20:18:10 2020 from 192.168.170.172
[root@server1 ~]#

Suggested Tutorial: Linux System Monitoring Tools & How To Use Them

NOTE: Adding the passphrase to the ssh-agent is not persistent except the ssh-agent process is persistent itself. Hence, when your server reboots, you will need to activate the ssh-agent again and add the passphrase to the ssh-agent again.

Suggested Tutorial: Tutorial Video On How To Effectively Extend LVM In Linux

Click: Tutorial Video On How To Configure Custom SSH key Based Authentication In Linux

Click: RHCSA Exam Practice Question & Answer On Configuring & Managing SSH in Linux

Your feedback is welcomed. If you love others, you will share with others

Be the first to comment

Leave a Reply

Your email address will not be published.


*