Background Knowledge

Benefits of Asymmetric Encryption

SSH keys always come in pairs: one public key and one private key. This implements the public/private key encryption method, also known as asymmetric encryption, which, at the absolute most basic level, means that you use your public key to encrypt and send to the reciever, and the reciever can get the message and decrypt it. This method is so secure because only the private key can decrypt the message, so the reciever can send the public key, anybody can encrypt a message, and only the intended reciever will be able to recieve the message. The integrity of this encryption method is maintained as long as the user is the only one with access to their private key, and does not share his private key with any other parties. This contrasts with symmetric encryption, which means that there is only one key (usually a password of some sort), which is used to both encrypt and decrypt messages, so whoever has this key can decrypt the message and view or modify the contents. This usually leads to problems, because the only way to send a private message would be to ensure that both parties have the same key, and the only way to securely send the key itself would be to encrypt it, leading to circular logic.

The problem with SSH password authentication

SSH keys use the same properties as asymmetric encryption, but in the context of SSH. Let’s define a Host (H), a Client (C), and a Third Party (O). If C wants to connect to H via SSH, conventially he would have to enter a password to prove that he is trusted by H, and that is the key that he is using. If we look at this in a more overarching viewpoint, this is a form of symmetric encryption: H has to give his password (encryption key) to C, so that C can connect securely to H. However, this rises the problem of how H will securely give C the password, making sure that O does not intercept the password and will now be able to log in to H. In order for H to give the password securely, the password will have to be encrypted, which again leads to the same problems.

NOTE
Many problems with symmetric encryption are not felt by people who just want to SSH from one laptop to another: they just have to remember their own password, and will not have to share any passwords, therefore not having any security risks. However, it is still beneficial to set up SSH keys, and even if you don’t care abou the extra security, you’l be able to sign in without having to use your password 😄

How asymmetric encryption solves it

In order to solve this problem, we can generate a public/private key pair for C. Then, C will give his public key to H. Whenver H recieves a request to connect, he can check if that public key is trusted. If it is, then H can allow the connection to take place.
You might be asking, how do we prevent O from showing C’s public key, and impersonating C?
The beauty of having a public and private key pair is that it is possible to prove your identity by using the private key to solve a challenge and return the result. Because O does not have the private key of C, he will fail the challenge and the connection will not go through.

How to set up a key pair

Now that we know the theory, let’s put it into practice! NOTE: All following shell commands should be executed on the CLIENT side machine, C, and not the host. You will need to know either the login details of the host machine or be in contact with the administrator of the host machine in order to execute all of the following commmands properly.

Firstly, we’ll want to actually generate a key pair. Type

ssh-keygen -C *email_address*

For example,

ssh-keygen -C nikhilc1527@gmail.com

Now you will get some prompts. Use the defaults for all prompts. If you wish to use a password for unlocking this key pair, you can, but it does not add much security (if you are the only one accessing this user). Finish off the process, and you should be notified that the key pair is stored in ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub. Naturally, the .pub file will contain the public key, which is shareable with everyone else, and the other file contains the private key, which should not be shared with anyone ever. Now that you have your key pair created, you can type

ssh-copy-id user@hostname

In order to install your public key on the host machine, you will need to give the login details of the host machine. If you do not have these details, and instead of you are in contact with the administrator of the machine, you can give them the ~/.ssh/id_rsa.pub file. Make sure the extension .pub is there, otherwise you are sharing your private key. Once they have your private key, they can append the first (and only) line of the public key file into the file ~/.ssh/authorized_keys on a new line. The method using ssh-copy-id will just append your public key into this file, so the end result is the exact same.