SSH keys are used to identify yourself to an SSH server, much like using a password. There's a couple of advantages in using SSH keys instead of typing in your password everytime you connect to a server:

- Less typing (for all the lazy people out there - including myself)
- No need to remember passwords (not that I'm saying it's a _good_ thing to forget passwords)
- The password is never transmitted, so it cannot be intercepted
- SSH keys are a lot harder to brute-force than your standard passwords (like "love", "sex", the name of your dog, or the birthday of your lover)

For the sake of this lesson, I will be using OpenSSH, because it's pretty much standard issue with most Unix-like systems, and my user account on anapnea, just because I have one there.

## Basic Understanding

SSH keys always consist of two parts - a **private** key, which will (hopefully) stay with you, and the **public** counterpart - that is the one that will be shared with the server(s) you want to connect to.

When you try to connect to the server, it will use the public key to encrypt a "challenge", which will then be send to your computer, and can only be decrypted with your private key. Think of this challenge as the big bearded guy looking through a peep hole, yelling "Password?" before granting you entry. Only that he's using some made-up language that only you can understand.

## Generating a Key Pair

A simple key pair can be genrated with a simple command:

This will generate a 2048bit RSA key

But we are not going to use that. For this tutorial, we will be using something a bit more custom:
(above command shamelessly ripped from the Archlinux Wiki)

- **-t ecdsa** ECDSA (Elliptic Curve Digital Signature Algorithm - Don't worry, I'm not going to quiz you on that) is the preferred algorithm since OpenSSH 5.7. Believe me, those people know what they are doing, so if they prefer it, it's good enough for me.
- **-b 521** We are generating a 521 bit long key. You could increase this value to make the key longer and safer, but keep in mind that a longer key will increase load and take longer while authenticating. ECDSA has equivalent security to RSA/DSA with smaller key sizes, so 521 should be sufficient, unless you work for the CIA.
- **-C "$(whoami)@$(hostname)-$(date)"** This is just a comment string. It's completely unnecessary, but it might help identifying the key later.

You will be asked where to save the generated keys. The default is ~/.ssh, and I would recommend leaving it at that. That is the place where every application will look for it. Changing this basically is asking for trouble down the road.

You will also be asked to enter a passphrase. It can be left blank for convenience, but then the key is saved unencrypted. This is a major security risk. On a single-user system it might be okay, on a multi-user system I would not recommend doing this.

If everything worked, you should something along the lines of this:

And you will have two files in ~/.ssh:
- id_ecdsa
- id_ecdsa.pub

## Moving the Public Key to the Server

There are two methods of moving the key to the server.

### Traditional Method

Transfer your key:
**Make sure you copy the public key, not the private one**

Hop on to the server:

Create ~/.ssh on the server:

Copy key to authorized keys:

Delete key file:

### Simple Method

The simple way to transfer the public key is using ssh-copy-id:

## Securing the authorized_keys file

On the server, make sure you set the permission for ~/.ssh/authorized_keys to 600, so it is only readable by yourself:

-------------------------------------------------

I hope this helped somebody. Happy SSHing!

Good guide!
I hate typing my password too.