Here is a short note on configuring passwordless logins between 2 Linux systems. Process basically involves generating a public authentication key and appending it to the remote hosts ~/.ssh/authorized_keys file.
Generate authentication key
If an SSH authentication-key file does not exist, generate one by running the ssh-keygen command. When prompted for a passphrase, use a blank passphrase if fully password-less login is required:
# ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/home/user/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/user/.ssh/id_rsa. Your public key has been saved in /home/user/.ssh/id_rsa.pub. The key fingerprint is: 1e:b2:f4:89:5a:7f:2d:a5:a5:4d:6d:66:2c:82:d8:18 root@remote-host
Copy the public key to remote host
Use the ssh-copy-id command to install the public half of the newly-generated authentication key into a specific user’s home directory on the remote host. The ssh-copy-id command will then automatically append the identity information into the ~/.ssh/authorized_keys file for the specified user on the remote host (creating ~/.ssh and~/.ssh/authorized_keys if necessary).
# ssh-copy-id -i ~/.ssh/id_rsa.pub user@remote-host user@remote-hosts's password:
Alternatively if the server is not installed with openssh-clients (a package which provides ssh-copy-id command utility) you can copy the authentication key with the command:
# cat ~/.ssh/id_rsa.pub | ssh user@remote-host "cat >> ~/.ssh/authorized_keys"
If everything is configured right, you should be able to login into to the remote host without password.
Troubleshooting
Check for the correct permissions
The most common cause of problems with getting key-based ssh authentication to work is file permissions on the remote ssh server
If the above steps were followed and ssh’ing to the appropriate user is still prompting for passwords, inspect the permissions on both the local and remote user’s files. The permissions of the directories should be exactly as show below. The example shown here is for the user “oracle”
drwx------. 25 oracle oinstall 4096 Aug 21 11:01 /home/oracle/ drwx------. 2 oracle oinstall 4096 Aug 17 13:13 /home/oracle/.ssh -rw-------. 1 oracle oinstall 420 Aug 17 13:13 /home/oracle/.ssh/authorized_keys
If the permissions are not as show abover, set them correct :
# chmod 600 ~/.ssh/authorized_keys chmod 700 ~/.ssh/
Restart the sshd service for the changes to take effect :
# service sshd restart
disabling SElinux
SELinux can also potentially prevent sshd from accessing the ~/.ssh directory on the server. This problem can be ruled out (or resolved) by running restorecon as follows on the remote user’s ~/.ssh directory:
# restorecon -Rv ~/.ssh
