Step by step guide for establishing passwordless ssh between two Unix or Linux servers. Authenticate securely using public and private keys.
If you are working in an infra where there are hundreds of Linux or Unix servers running, then you must be having big-time while managing them. To deal with such a large number of servers, passwordless ssh becomes a must-do practice. Once you can achieve remote execution of scripts, commands, sync files via SCP, etc tasks with passwordless ssh very easily.
Passwordless ssh is not compromising on security. You will be using a pair of user-generated keys for authentication so your security is not compromised. It’s totally secured, the only thing is you are being authenticated already saved keys rather than a human entered password. This removes the dependency of entering a password and hence automatize the whole process non-interactively.
This is a very short and handy process to set up passwordless SSH between two servers.
kerneltalks1 : the server we are going to configure passwordless SSH from
kerneltalks2 : the server to which we need password less SSH
shrikant : the user ID for which password-less SSH needed from
On kernetalks1 (First server)
Generate SSH key using
ssh-keygen command. Make sure you are logged in with user
shrikant (your user for which password less ssh is needed)
[shrikant@kerneltalks1 ~]$ ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/home/shrikant/.ssh/id_rsa): Created directory 'https://z5.kerneltalks.com/home/shrikant/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/shrikant/.ssh/id_rsa. Your public key has been saved in /home/shrikant/.ssh/id_rsa.pub. The key fingerprint is: SHA256:VO+kDv6iXtglzlIeC9OslZK14jKSVoPJKMNevMS/pp8 shrikant@kerneltalks1 The key's randomart image is: +---[RSA 2048]----+ | . | | . . | | o o | |.ooo * o + | |+.+=o * S o . | |o.oooo / B | | .+.o.= O . | | . . +oo.. | | .+Eo. .. | +----[SHA256]-----+
Now, you need to copy this generated key to target server i.e.
kerneltalks2. Copy key using
[shrikant@kerneltalks1 ~]$ ssh-copy-id kerneltalks2 /bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/shrikant/.ssh/i d_rsa.pub" /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 n ow it is to install the new keys shrikant@kerneltalks2's password: Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'kerneltalks2'" and check to make sure that only the key(s) you wanted were added.
And that’s it. You have configured password-less SSH by just 2 commands from one server. You can test it out by doing simply ssh and it should not ask you for any password!
[shrikant@kerneltalks1 ~]$ ssh kerneltalks2 [shrikant@kerneltalks2 ~]$ hostname kerneltalks2 [shrikant@kerneltalks2 ~]$ id uid=1001(shrikant) gid=1002(shrikant) groups=1002(shrikant) context=unconfined_u :unconfined_r:unconfined_t:s0-s0:c0.c1023 [shrikant@kerneltalks2 ~]$ exit logout Connection to kerneltalks2 closed.
All the above processes can be chopped into smaller chunks and manual commands to understand what actually happens in the background. Follow the below manual setup to configure passwordless ssh access.
Lets see how to setup password less ssh between two servers:
Create your SSH key pair on the source machine. This is a machine from which you will be doing password less SSH to the destination machine.
Use below command :
$ ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/user4/.ssh/id_rsa): Created directory 'https://z5.kerneltalks.com/home/user4/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/user4/.ssh/id_rsa. Your public key has been saved in /home/user4/.ssh/id_rsa.pub. The key fingerprint is: ad:1e:14:a5:cd:77:25:29:9f:75:ee:4f:a4:8f:f5:65 user4@server1 The key's randomart image is: +--[ RSA 2048]----+ | . ...| | = . .oo| | o o .o.+.| | o . .o o| | S . + | | . . . E| | o *+| | . . . +| | . | +-----------------+
Note that your key pair is
id_rsa.pub files in shown directories. Your
id_rsa is a private key that will reside on the source machine.
id_rsa.pub is a public key that resides on the destination machine. When the SSH attempt is made from source to destination, protocol checks these both keys from source and destination. If they match then the connection will be established without asking a password.
Now, we need to copy
id_rsa.pub key on the destination machine. It should be copied to the home directory of the intended user in the destination server. It should reside under
~/.ssh/ (i.e. home directory/.ssh/) and with name
authorized_keys. You can copy the file using a shell or any other file transfer program.
If you are trying from source machine using ssh then use below commands:
$ ssh email@example.com "mkdir ~/.ssh" The authenticity of host '10.10.4.12 (10.10.4.12)' can't be established. RSA key fingerprint is 08:6c:51:09:9f:4c:69:34:84:ef:08:af:68:df:5e:24. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '10.10.4.12' (RSA) to the list of known hosts. firstname.lastname@example.org's password: $ cat .ssh/id_rsa.pub | ssh email@example.com 'cat >> .ssh/authorized_keys' firstname.lastname@example.org's password: $ ssh email@example.com "chmod 700 .ssh; chmod 640 .ssh/authorized_keys" firstname.lastname@example.org's password:
Here, the first command creates
.ssh directory on the destination machine. Second command copies
id_rs.pub file’s content to destination machine under file
~/.ssh/authorized_keys and last command sets proper permissions.
You are done! Try SSH from source to destination and it will be through without password!
$ ssh email@example.com Last login: Tue Oct 6 21:59:00 2015 from 10.10.4.11 [user4@server2 ~]$
This method works for all Linux and Unix variants for SSH protocol. You can also configure it for different users on the source and destination. One machine can have more than one authorized key (one key for one source machine), that’s why we have concatenated
id_rsa.pub content to
authorized_keys file (not overwrite).
Drop us any suggestions/corrections you have in comments.