Introduction

Configuring passwordless ssh authentication between users on the same or different systems is a common task for a system administrator. Following the available steps is simple enough but we may often find ourselves in annoying situations when we follow the steps exactly and the setup does not work. In this article, we will show you how to configure passwordless ssh authentication between two users with the same username on 2 different systems. Given below is an overview of our intended setup: username: sahil source server IP: 192.168.188.133 (centos 7) destination server IP: 192.168.188.129 (centos 6)   Step 1: Generate ssh authentication keys: Let’s log in to our source server and generate an ssh key pair which we will use for authentication. To do this we use the ssh-keygen command as shown below:

[sahil@linuxnix1 ~]$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/sahil/.ssh/id_rsa):
Created directory '/home/sahil/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/sahil/.ssh/id_rsa.
Your public key has been saved in /home/sahil/.ssh/id_rsa.pub.
The key fingerprint is:
61:67:54:87:e2:1c:a2:d9:ac:34:e7:f3:17:9c:9e:e5 sahil@linuxnix1
The key's randomart image is:
+--[ RSA 2048]----+
| ..... |
| ..o .. |
| =o+oo |
| =.++o |
| . =S . . |
| . o + . |
| o . = |
| . + E |
| . |
+-----------------+

In the above example, we are generating an RSA public-private key pair as specified by -t (type) RSA with the ssh-keygen command. We could also generate a DSA keypair by typing -t dsa with ssh-keygen command. DSA keys provide a higher level of encryption as compared to RSA keys. When prompted for a passphrase, use a blank passphrase by pressing the enter key since we require a fully password-less login process. Note: Generally if you use a passphrase while generating ssh keys, you might consider disabling password-based authentication altogether in the sshd_config file and use ssh keys alone.   Step 2: Copy the public key to remote host The ssh-keygen command executed in the previous step generates a public-private RSA key pair.

[sahil@linuxnix1 ~]$ cd .ssh
 [sahil@linuxnix1 .ssh]$ ls id*
 id_rsa id_rsa.pub
 [sahil@linuxnix1 .ssh]$

For the passwordless authentication set up to work, we need to append the RSA public key to ~.ssh/authorized_keys file for the specified user on the destination server. You may need to create the authorized_keys file if it does not exist already. We can manually append the RSA public key file by using the cat command or by copying the key and pasting the content inside the authorized_keys file via a text editor. Or we could also use the ssh-copy-id command. We will show you how to remotely append the key using the cat command and also by using the ssh-copy-id command.

[sahil@linuxnix1 ~]$ cat .ssh/id_rsa.pub | ssh sahil@192.168.188.129 'cat >> .ssh/authorized_keys'
The authenticity of host '192.168.188.129 (192.168.188.129)' can't be established.
RSA key fingerprint is d3:f6:c5:8d:88:73:c0:60:da:3e:3c:4e:cf:44:06:78.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.188.129' (RSA) to the list of known hosts.
sahil@192.168.188.129's password:
[sahil@linuxnix1 ~]$
[sahil@linuxnix1 ~]$ ssh-copy-id -i ~/.ssh/id_rsa.pub sahil@192.168.188.129
/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
sahil@192.168.188.129's password:

Number of key(s) added: 1

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

  Step 3: Verify passwordless login Now that we have copied across the RSA public key for our user, we should be able to login to the destination host without a password.

[sahil@linuxnix1 ~]$ ssh sahil@192.168.188.129
 Last login: Tue Jan 2 17:55:57 2018 from linuxnix2
 [sahil@linuxnix2 ~]$

  Now that we have shown you how to configure passwordless ssh authentication for a user, let’s dive into troubleshooting common problems that may prevent the setup from working. Permission issues: Passwordless ssh setup is very sensitive to permission issues. Here a couple of permission caveats to be aware of. The users’ home directory should not be writable by anyone except the user itself. The permission for the .ssh directory must be 700. The permissions for the RSA key files and the authorized_keys file should be 644 or lower. If any of the above permission requirements are not met, then passwordless ssh authentication will not work.   SELinux issues: SELinux can also potentially prevent sshd from accessing the ~/.ssh directory on the server. This problem can be resolved by running restorecon as follows on the remote user’s ~/.ssh directory.

# restorecon -Rv ~/.ssh

  Group memberships: Some systems often make application users part of a sshdeny group and add a denygroup directive in the sshd_config file for this group to restrict direct ssh login for such users. Make sure that the user you are working with is not a part of this group.   User account status: Passwordless ssh logins can work among users that have NL or no-login flag set which means that they don’t have a password set. But passwordless ssh logins will not work if the specified user is locked.   The integrity of the authorized_keys file: This shouldn’t be an issue if are using the ssh-copy-id command or using the cat command to append the public keys into the authorized_keys file. But if we are using a text editor like vi then you might need to be cautious. If there are any spaces or line breaks in the key being appended to the file, that key is considered as corrupted and will not work. It may even corrupt the entire authorized_keys file preventing other passwordless ssh setups from working.  

Conclusion

In this article, we showed you how to configure passwordless ssh authentication between two users and we then discussed some scenarios which may prevent the setup from working. We hope that you’ve found this article to be helpful and we look forward towards your suggestion and feedback.

Post Views: 10,282
The following two tabs change content below.

Sahil Suri

He started his career in IT in 2011 as a system administrator. He has since worked with HP-UX, Solaris and Linux operating systems along with exposure to high availability and virtualization solutions. He has a keen interest in shell, Python and Perl scripting and is learning the ropes on AWS cloud, DevOps tools, and methodologies. He enjoys sharing the knowledge he's gained over the years with the rest of the community.