Ssh keys

An ssh key is a way of identifying (authenticating) yourself when connecting to a server via ssh. A different popular authentication method is entering a password.

Why should I use it?

When you connect to a server, authenticating via a password there are two main problems:

• Someone could bruteforce or guess your password, since many passwords are commonly weak or used for multiple applications.
• Someone could intercept your password, since it has to be send to the server at some point in some form.

How-to-use-it

Generate a key

You should start by generating a key pair:

$ ssh-keygen -b 4096

where you can specify the max length of the key up to 16384 bits.

You can then optionally protect your key with a passphrase. (Your key is basically just a file sitting on your computer and a passphrase protects your key, if someone happens to steal/copy that file).

If you did not specify a different file, the key normaly gets generated into the folder

~/.ssh

with the files id_rsa being your private and id_rsa.pub being your public key.

Copy the public key to the server

Method A

This public key now has to be copied to the server into the ~/.ssh/authorized_keys file. This can be done, by opening an ssh connection via password and then using an editor (e.g. vim) to paste the key into the file (creating the .ssh directory beforehand if it does not exist):

$ mkdir -p ~/.ssh
$ vim ~/.ssh/authorized_keys

Method B

Instead of performing the copying of the ssh key to the server manually, you can use the program ssh-copy-id to achieve the same goal:

$ ssh-copy-id <username>@<remote-host>

where <username> is your username on the remote host <remote-host>. You will be prompted for your password and the program will manage the rest.

Regardless of the method used, the next time you ssh to the server, it should use the key and instead of prompting for the user's password, prompt for the passphrase of the key (if you chose to employ one).

Troubleshooting

If it still asks for your password, something went wrong. In that case you should check, whether the authorized_keys file really contains the key by executing:

$ cat ~/.ssh/authorized_keys

on the server and

$ cat ~/.ssh/id_rsa.pub

on your local machine. If the key of your local machine is not contained in the authorized_keys on the server, repeat the steps of copying the key to the server.

You should also make sure, that correct file access permission are set. If unsure, execute:

$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/id_rsa
$ chmod 640 ~/.ssh/id_rsa.pub
$ chmod 640 ~/.ssh/authorized_keys
$ chmod 640 ~/.ssh/known_hosts
$ chmod 640 ~/.ssh/config

How-it-works

The basic principle is that of asymmetrical cryptography being employed by using a public-private-key-pair. A public key is like an indestructible piggy bank: Everybody can put something (data) into it, but nobody can get it back out again. A private key is the key for this. In this way you can distribute all the piggy banks you like and if someone put something in there and sends it back, only you can open it with your private key.

Now since you gave the server the public key (=piggy bank), it can encrypt something (say a random number), send it back and only you can decrypt this number, since only you have the private key.

For more detailed information on how this works, head over to the References.

References

SSH keys on the archlinux wiki

Public and private keys easily explained

More detailed explanation of the connection and encryption process of ssh