How to Configure Passwordless SSH in Linux

SSH is a protocol to transfer data securely between different machines. The SSH protocol uses public-key cryptography to allow the client to authenticate the server and if necessary to allow the server to authenticate the client without sending passwords back and forth.

Public Key Cryptography uses a public-private-key-pair. The private key is kept secret and is never transferred over the network. The public key may be distributed to all peers. Messages encrypted using the public key can only be decrypted with the private key. At SSH connect time, the client receives the server’s public key, and verifies if this matches the stored public key in $HOME/.ssh/known_hosts. If this test is successful, and the server does not have the client’s public key, a password is required. Else, the server sends a message encrypted with the client’s public key and if the client manages to decrypt the message successfully, using its private key, the connection is established.

There are two versions of the SSH protocol, version 1 and 2. The encryptions are tied to the protocol version. Version 1 suffers from security vulnerabilities, whenever possible, version 2 should be used. Most SSH-servers use version 2 of the protocol due to the limitations of version 1. There are 2 algorithms for the encryption of public-private-key-pairs, RSA and DSA.

Client Setup

Protocol Type Commandline
Version 1 RSA1 -t rsa1
Version 2 RSA -t rsa
Version 2 DSA -t dsa

After determining which identity type you want/need, the first step is to generate a public-private-key-pair and copy the public part into the appropriate place on the server-side. In the user’s home directory, on the client machine, execute (you should have the directory $HOME/.ssh, if note create it):

$ ssh-keygen -t dsa -f .ssh/id_dsa Generating public/private dsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in .ssh/id_dsa.
Your public key has been saved in .ssh/
The key fingerprint is:
d9:cd:37:11:7b:76:f4:be:xx:xx:xx:xx:xx geek@[hostname]

Here, -t is used for the type of encryption -f where to store the public/private key pairs. In this case, the .ssh directory on user home.

A passphrase will be asked; leave this part blank, just pressing [enter] if you do not want to type this passphrase at every connect. Alternatively, one could set up an ssh-agent to handle the passphrases, although this note does not handle such a process.

The above command creates two files in ~/.ssh:

$ ls -l .ssh
total 8
-rw------- 1 geek geek 672 Oct 24 10:44 id_dsa
-rw-r--r-- 1 geek geek 619 Oct 24 10:44

Example on the difference between if with and without passphrase:

$ ssh [email protected]
Enter passphrase for key '/home/geek/.ssh/id_dsa':
Last login: Fri Nov 13 21:35:52 2015 from [hostname]
$ ssh [email protected]
Last login: Fri Nov 13 21:36:19 2015 from [hostname]

Server Setup

The file contains the client public key, which needs to be appended to the file $HOME/.ssh/authorized_keys on the server:

Copy the file to the server:

client$ scp ~/.ssh/ user@server:~/.ssh/

Of course, this time you will need to enter the password for the user.

Now, log on the server machine and go to the .ssh directory on the server side

client$ ssh user@server
server$ cd .ssh

Now, add the client’s public key to the know public key list on the server:

server$ cat >> authorized_keys
server$ chmod 640 authorized_keys
server$ rm
server$ exit

that’s all.

If there are SSH version1 clients around, might be interesting to create a symbolic link for the version 1 authorised keys list on the server:

$ cd $HOME/.ssh && ln -s authorized_keys authorized_keys2


$ ssh -l [user] [server]
Last login: Tue Oct 23 15:20:07 2007 from

or alternatively

$ ssh [user]@[server]
Last login: Tue Oct 23 15:20:07 2007 from

If the system did not query you for a password everything is working properly.


Make sure that you keep your private key (~/.ssh/id_dsa) secret! While it is safe to give your public key (~/.ssh/ to the world, you should be extremely careful that nobody else can read your private key (~/.ssh/id_dsa). Everybody who has access to the private key can log in to any machine where the matching public key is installed.