SSH for beginners

Author: Etienne Barrier Last modified: 19.04.2016

Introduction

This tutorial-like article is intended for beginner users who would like to learn about SSH cryptography protocol from scratch and/or get a deeper understanding of it.

It has been made using Linux Ubuntu 14.04 distribution, therefore we cannot guarantee that the information is relevant for other Linux distributions or for Windows or MAC.

It is assumed that you are already familiar with the basics of Linux command line terminal commands. We are not going to explain the commands which are not directly related to SSH.

SSH was built based on a client-server architecture and we are focusing only on the client side of SSH. See here for SSH on server side for Ubuntu [1]

For any comments to the author of this article, please send an email to etienne(dot}barrier{at]itcollege[dot)ee [put picture]

A bit of history

The SSH protocol was invested in 1995 by the Finnish Tatu Ylönen who was a researcher at the Helsinki University of Technology in Finland. He decided to develop his own remote connection protocol after an attack performed against his university. He published the source code if his protocol and everyone could use it for free. SSH gained popularity very rapidly and Tatu understood that SSH could become something much bigger. Consequently, he founded his company the same year, called SSH Communications Security, to develop and sell his service around SSH. Tatu Ylönen is still the CEO of the company (ssh.com/about/management).

SSH version 1 was relased and documented in 1995 but its problems also emerged as it was used by a steadily number of users. Meanwhile, a working group called SECSH at the IETF (Internet Engineering Task Force - https://www.ietf.org) started to work on the version 2. When the version was released in 1998, it was not widely adopted because its licensed was more restrictive than the first version: it is was not free for commercial use.

In the years 2000 however, the loosening of the license terms combined with the development of a fork of the first version under the OpenBSD license called OpenSSH, boosted its interest. As for today, the OpenSSH implementation is the most widely in the open-source world.

http://docstore.mik.ua/orelly/networking_2ndEd/ssh/ch01_05.htm

http://www.jeffgeerling.com/blog/brief-history-ssh-and-remote-access

The concepts of SSH

SSH is the acronym of "Secure SHell". It is a cryptographic protocol but also a program (or a set of utilities) that allows two computers to exchange encrypted messages over an unsecured network (like internet). This protocol is used to do many things: encrypt a connexion (without authentication), authenticate a host, share files, remote terminal, SSH tunneling, etc.

Why to use an SSH connection to access a remote host?

The main reason to do all this via SSH is security, because the data between the two hosts is encrypted. SSH has almost completely replaced Telnet and FTP protocols which transfer data in plain text. With Telnet or FTP, if somebody listens to your traffic, it will be extremely easy to get all the data, including the passwords.

SSH has become a standard to establish a connexion between two computers and a good practice regarding privacy and security standards.

Types of encryption

To encrypt the data, it can use different types of encryption: DSA, RSA, RSA1, ECDSA and Ed25519. The type of encryption depends on some mathematical properties it uses to generate random keys which are really hard to guess using a reverse model of these mathematical properties. The type RSA1 is from the SSH protocol version 1 which is obsolete and should not be used. All others are part of SSH protocol version 2 but DSA should not be used because it has vulnerabilities found in 2015 [link].

From the remaining RSA, ECDSA and Ed25519, RSA is the most widely used although it not as efficient and "strong" as the other ones (in theory). The main advantage of ECDSA and Ed25519 is that they provide the same level of security than RSA but with shorter keys (256-bit key for ECDSA/Ed25519 is equivalent to 3000-bit RSA key) [link]. But RSA remains the most popular type because all SSH clients are compatible with it and until now, it has remained unbreakable. RSA, ECDSA and Ed25519 types are so far considered unbreakable.

Private and public keys

To perform its encryption, SSH will create 2 digital keys: a public key and a private key. The public key is not confidential, anybody can have it (thus the name "public"). On the contrary, your private key must remain secret and accessible only by you! Your public key is not secret because it must be stored in each server/computer/device you will want to access with your private key. Your private key is the only one that can match its public key, that is why they form a pair. The public key is like the same lock that you install on several doors. All those doors which have this (public) lock can be opened by you because you have the only (private) key that can open this lock.

The keys are by default stored in the hidden folder .ssh in the user's home directory. The private key will be a file named "id_rsa" and the public key a file named "id_rsa.pub". If you create keys of other types than RSA, they will be named id_<keyType> and id_<keyType>.pub (ie. id_ecdsa.pub).

Passphrase

During the generating process, you will be asked to enter a passphrase. A passphrase is basically a password, but whereas a password is usually considered a single "word" (or string) of variable length, a passphrase is an arrangement of words separated by space. Passphrase is usually considered safer than passwords because it is usually longer than passwords. Its main advantage is that it is considered easier to remember. Read here how to choose a strong passphrase: http://windows.microsoft.com/en-us/windows7/tips-for-creating-strong-passwords-and-passphrases.

The passphrase is used to access the content of your private key. Although you can choose to not to enter a passphrase it is recommend since in case your private key gets stolen, the thief will need to first break your passphrase before he can use it: it will give you time to remove the public key from all the places you have put it, therefore the private key will become useless even if the passphrase is broken.

If you forget your passphrase, it cannot be retrieved. Should you be in this situation, you must generate new keys and replace your old public key by the new one in all the servers where you placed it.

Authorized keys

Your public key must be placed on all servers that you want to access remotely. More specifically, your public key must be insert in a new line of the file ~/.ssh/authorized_keys located on the server. This file contains all the public keys of all the clients that are authorized to access the server via SSH. This is the reason why your private key must remain secret: anybody with your private key file can access all servers where your private key is written in the authorized_keys file. If your key gets stolen, you must remove the line where your key appears in this file on all servers where it is present.

Known-host and key fingerprint/randomart

SSH connexion is very safe, but it is vulnerable to a man-in-the-middle attack when you connect to a server the first time. When you access a server with SSH for the first time, the server will send you its public key (which is its identity), and you will see a message that looks like

The authenticity of host 'mint.phcomp.co.uk (78.32.209.33)' can't be established. 
RSA key fingerprint is 6a:de:e0:af:56:f8:0c:04:11:5b:ef:4d:49:ad:09:23. 
Are you sure you want to continue connecting (yes/no)?

Instead of displaying the whole key (which is hard to read), the terminal shows you a more readable MD5 hash of it: this is the fingerprint. Both keys of an SSH pair (public and private) have the same fingerprint.

You then must make sure that this fingerprint is the one that you supposed to get: either you already know what the fingerprint should be, or you can know what it is yourself, or you must ask another person who knows it. If the fingerprint displayed on the terminal is the one expected, you can continue and type "yes". If it is not the one expected, you are probably trying to connect to a server that is fake, and you should deny connexion and contact the administrator or perform a security check.

Once you establish a connexion to a server for the first time with SSH, the server's public key information will be stored as a new line in the file "known_hosts" of the .ssh directory. Each line of this file correspond to a server which you have successfully connected before. When the server's public key you connect to is in this file, the connexion will be established without asking you to verify the server's identity once again: it is a known host already.

If you still find the fingerprint hard to read, SSH provides the randomart, which is a more visual representation of the fingerprint. It makes it easier and faster to compare keys.

SSH in practice

We are covering several study-cases which are the most common ones you may encounter. In all of them, it is assumed that SSH package is installed on your machine (comes by default on Ubuntu), and that the remote host (which we will call "server" from now on) has also enabled SSH remote access.

Create/Generate SSH keys

To establish an SSH connection to a server, you must first generate your pair of public and private keys.

The simplest way to generate the keys is to use the following command which will by default create a set of 2048-bit size RSA keys:

ssh-keygen

Then you will be asked a path where to save the key. We suggest you save it in the default location by just hitting Enter. Then you will be asked to enter a passphrase, which we recommend to do, although it is not compulsory.

That's all, your keys are generated! The whole process looks like this in your terminal:

ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/<username>/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase):  
Enter same passphrase again:  
Your identification has been saved in /home/<username>/.ssh/id_rsa. 
Your public key has been saved in /home/<username>/.ssh/id_rsa.pub. 
The key fingerprint is:
76:99:9d:fa:42:40:a2:65:59:ca:26:6f:4d:0c:04:e2 johndoe@johnPC
The key's randomart image is:
+--[ RSA 2048]----+
|  . .ooo.        |
| . . .=+.        |
|  E .++oo        |
|    .+ o.  + .   |
|      o S.+ o    |
|     . . ...     |
|         ..      |
|          ..     |
|           ..    |
+-----------------+

Please note the fingerprint and the randomart of your keys (see previous section).

There are many options you can add the the command. Here is a list of the most useful ones:

-t is to set up the type of encryption. For example ssh-keygen –t ecdsa

-b is to set the number of bits in the key to make it longer: For example ssh-keygen –b 4096 Making the key longer increases security but also slows down connexion as every packet has to be decrypted (high CPU usage). [2]. For RSA, 2048 bits is considered sufficient. Maximum number of bits is 13384: [3] For ECDSA type, three values are possible 256, 384 or 521 bits (an error is thrown otherwise). The number of bits does not apply to Ed52219 type (always 256 bits).

-C is to set a comment for this key: for example ssh-keygen –C "My personal laptop". Double quotes are required if you have space(s) in your comment. This comment is placed at the end of your public key in plain text. It becomes very handy if you have several computer with different private keys on each of them. The comment can be used to identify to which it is linked to. For example suppose you have two computers with different private keys. You have put one of their public keys to your server but you do not remember which private key (computer) matches it. If you have a comment in your public key which identifies the client host which holds the corresponding private key, this is not a problem. In case you have not set a comment when generating your keys, you can add it later. Just open the public key file, add a space in the end of the key, and write your comment (spaces are allowed). Example: http://serverfault.com/questions/442933/add-comment-to-existing-ssh-public-key. Ultimately, you could write a different comment on each server where you place your public key.

Take a look at your keys in your .ssh folder.

Copy public key to server

Now that you have generated your keys, you must place your public key inside your server. More precisely you must insert your public key inside the file ~/.ssh/authorized_keys on the server.

Here are two commands to achieve it:

cat ~/.ssh/id_rsa.pub | ssh <user>@<hostname> 'cat >> ~/.ssh/authorized_keys'

Or

ssh-copy-id <user>@<hostname>

Establish connection to the server

When you will connect to the server for the first time, you will be ask to check the fingerprint of the server's public key.

ssh <user>@<hostname>

example: ssh johndoe@enos.itcollege.ee

If you have access the public or private key of the server, you can get their fingerprint with this command:

ssh-keygen –lf <keyPath>

If you cannot access the server's keys to get the fingerprint by yourself, you should ask someone who can.

Manage keys

Usually you create one pair of keys per computer you have. But you can create as many keys as you want if needed. To have several keys of the same type you can change their file name and/or file path. But SSH utility will look for the default key file names (id_<keyType>) in the default directory (~/.ssh/). To connect to a server using a non-default private key, we can specify its path:

ssh -i <privateKeyPath> <user>@<hostname>

Delete keys

To delete a set of keys, you can delete their files directly.

If you want to remove some servers from your "known_hosts" file, it is not possible to understand what they are by reading the content of the file. But you can remove a particular one with this command:

ssh-keygen –R <hostname>

References

https://kb.iu.edu/d/aews

http://support.suso.com/supki/SSH_Tutorial_for_Windows

http://security.stackexchange.com/questions/20706/what-is-the-difference-between-authorized-key-and-known-host-file-for-ssh

https://help.ubuntu.com/community/SSH/OpenSSH/Keys

http://man.openbsd.org/ssh.1

http://man.openbsd.org/OpenBSD-current/man1/ssh-keygen.1

http://www.howtogeek.com/114812/5-cool-things-you-can-do-with-an-ssh-server/

https://wiki.archlinux.org/index.php/SSH_keys

http://ed25519.cr.yp.to/

https://blog.cloudflare.com/ecdsa-the-digital-signature-algorithm-of-a-better-internet/

http://www.howtogeek.com/114812/5-cool-things-you-can-do-with-an-ssh-server/

https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys--2

http://6ftdan.com/allyourdev/2015/02/12/setting-up-remote-ssh-access-to-your-ubuntu-box/

http://searchsecurity.techtarget.com/definition/Secure-Shell