The ssh files (2)

Last Updated on 2022-07-08 by Joop Beris

Welcome to the second instalment of the ssh files. In this instalment, we’ll be taking a look at logging in without a password, using public key authentication. The major benefit of logging in through public key authentication, is that you will only have to remember the pass phrase of your key and no longer a dozen or more passwords on different servers. Also, setting your ssh daemon to only allow public key authentication will foil any attempts by script kiddies to brute force your password…because there isn’t one.

To be able to use public key authentication on your ssh daemon, you need to do two things. One is to tell the daemon to accept public key authentication and the other is to obtain your own key. Fortunately, the last bit is easy enough because you can make one yourself. Your key will consist of two parts, one part private, the other part public. Let’s take a look at how public key authentication works and then we’ll set it up for ourselves.

How public key authentication works

As mentioned above, for public key authentication, you need to have a key pair. The pair consists of two keys obviously, one is the public key, the other is the private key. The public key is the key that you distribute (hence: public), the private key should never be given away and closely guarded. The key pair is generated on the client machine, the machine you will be connecting from. The server is the machine you will be connecting to. The magic is that using one key you can encrypt a message that can only be decrypted with the other key. That’s the reason that you need to distribute your public key. Using the public key, the server will encrypt a message intended for your client. Only your client, that holds your private key, can decrypt this message. No other computer in the world will be able to do this (well, shouldn’t anyway). This demonstrates why this type of authentication is very difficult to break. Someone would need to have both parts of the key and the pass phrase for the private key (if there is one) to be able to read messages passed between the client and the server.

When your client connects to the server, the server will send your client a message encrypted with your public key. Since your client holds the corresponding private key, it can decrypt the message (possibly after you enter your pass phrase) and so it can send back the correct response to the server, also encrypted of course. This proves to the server that it is you (your client) trying to log in and the connection is allowed.

That is the theory behind it, now let’s set it up.

Creating your key pair

To begin, we will first generate the public/private key pair on the client. This is done using the command line tool ssh-keygen. So open up a console window and enter the following command.

# ssh-keygen -t rsa

You will be prompted to enter a pass phrase and I strongly urge you to do so! The pass phrase will further protect your private key, making this type of authentication a lot more secure. If you don’t, anyone who obtains a copy of your private key will be able to use it to log in to any server where you have put your public key.
If all things go well, the ssh-keygen tool will generate two files in ~/.ssh: id_rsa and id_rsa.pub. The first file is your private key, the second is your public key. The private key should be left in place, the public key is the file you will be distributing to the server.

Distributing your public key

You can do this pretty much any way you like. You can copy it to a USB thumb drive, you can send it to the server admin via email or, if you can log in through ssh already, you can copy it to the server as follows.

# ssh-copy-id -i  ~/.ssh/id_rsa.pub user@example.com

The ssh-copy-id program takes care of adding the public key to the user’s ~/.ssh/authorized_keys file on the remote server. Once they key is on the remote server, you should be able to log in without a password, though you will be prompted for your pass phrase to unlock the private key (you did create a pass phrase, didn’t you?).
Alternatively, if your client doesn’t have the ssh-copy-id program, you can use good old scp.

# scp ~/.ssh/id_rsa.pub user@example.com:./ssh/authorized_keys

This command will use the secure copy (scp) program to transmit your local public key to your home directory on the server example.com with file name authorized_keys.
It doesn’t really matter how the file gets there, as long as it is placed in the .ssh directory inside your home directory with the name authorized_keys. With that step done, our key pair is ready for use. Now we just need to make sure the server allows public key authentication.

Setting up the ssh daemon to allow public key authentication

To set up the ssh daemon to allow public key authentication, you will probably need to edit its configuration file. On Fedora and openSUSE, this file can be found in /etc/ssh and is called sshd_config. Don’t confuse it with ssh_config, which is in the same directory! In the file sshd_config, look for the following line.

#PubkeyAuthentication yes
#AuthorizedKeysFile     .ssh/authorized_keys

Uncomment the lines by removing the pound sign and making sure that the PubkeyAuthentication line says ‘yes’ at the end. Now save the file and restart the ssh daemon and you are good to go. However, to be complete and if you don’t need password authentication any more, you may as well turn it off altogether. To do this, change the following line in sshd_config.

PasswordAuthentication yes

Either comment out this line by adding a pound sign in front of it or better yet, set it explicitly to ‘no’. Restart your ssh daemon to activate the new configuration. Congratulations, you have just set up public key authentication and frustrated a lot of script kiddies who will be busy trying password after password but never getting in.

If things don’t work

If things don’t work, here’s a couple of things to check.

• Make sure that the client has the following files in the ~/.ssh directory: id_rsa and id_rsa.pub. If not, there’s no private or public key or both. Run the ssh-keygen program as stipulated above.
• Make sure that the server has the public key stored in the ~/.ssh/authorized_keys file. If not, copy the public key into it using one of the methods described above.
• If your pass phrase is not accepted, make sure you entered it correctly. If necessary, you can change the pass phrase using the ssh-keygen -p command.
• Try to login, but make ssh verbose by adding -vvv to the command line (see previous instalment of the ssh files).
• Make sure the permissions on the id_rsa and id_rsa.pub files are set correctly. They should look like below.

-rw-------.  1 user group 1766 Jun 21 01:02 id_rsa
-rw-r--r--.  1 user group  402 Jun 21 01:02 id_rsa.pub