crshd Using SSH Keys instead of Passwords

Thursday, September 20, 2012 – Security

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 “Passwort?”, 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:

$ ssh-keygen -t rsa

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:

$ ssh-keygen -t ecdsa -b 521 -C "$(whoami)@$(hostname)-$(date)";

(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:

Generating public/private ecdsa key pair.
Enter file in which to save the key (/home/crshd/.ssh/id_ecdsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/crshd/.ssh/id_ecdsa.
Your public key has been saved in /home/crshd/.ssh/
The key fingerprint is:
c3:c3:ec:4e:f9:7a:ff:e5:54:e1:e3:dc:c1:e1:3b:00 crshd@tatooine-Mo 17 Sep 2012 01:31:31 MYT
The key's randomart image is:
+--[ECDSA  521]---+
|                 |
|                 |
|           E   o |
|       +    . + o|
|        S    . *.|
|       . +    + *|
|        +      =+|
|       o ..    +.|
|        oo..... .|

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

Moving the Public Key to the Server

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

Traditional Method

Transfer your key:

$ scp ~/.ssh/

Make sure you copy the public key, not the private one

Hop on to the server:

$ ssh

Create ~/.ssh on the server:

$ mkdir ~/.ssh

Copy key to authorized keys:

$ cat >> ~/.ssh/authorized_keys

Delete key file:

$ rm

Simple Method

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

$ ssh-copy-id -i ~/.ssh/

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:

$ chmod 600 ~/.ssh/authorized_keys

I hope this helped somebody. Happy SSHing!