previous episode

Introduction to Cloud

Creating a keypair

next episode

Overview

Teaching: 20 min
Exercises: 0 min
Questions

  • What is a shell?

  • What is SSH?

  • What are key-pairs and how do you create one?

  • How do you view and set file permissions?

Objectives

  • Learn some basic Linux commands.

  • Create a key pair.

Now that you have an overview of OpenStack and have clicked around the dashboard it is time to create our first virtual machine. To create a virtual machine, we would click the Launch Instance button on the Instances panel, but before we do that there is one thing we need to take care of first and that is creating a key (and lock) to access our newly created virtual machine. The key will allow only the person possessing it to access the VM. You wouldn’t want just anyone connected to the Internet to access your newly created VM. While creating a virtual machine we need to select a lock, corresponding to a key we posses, to be put on the virtual machine.

Password Authentication & Brute force attacks

Password authentication could be used rather than ssh keys to access VMs, however, password authentication susceptible to brute force attacks. A brute force attack is when many usernames and passwords are attempted, usually in an automated way, to try and gain access. Brute force attacks are exceedingly common and often in a few minutes to days any computer accessible publicly over ssh will receive a brute force attack. SSH keys are the best way to thwart these attacks, but if password authentication is really needed it must be combined with some method of mitigating brute force attacks such as fail2ban, which is a program that bans any IPs with multiple failed ssh connection attempts.

Another great way of controlling access is to restrict which IP address can connect to your VM. We will see how to do that shortly. In general though, it is best have security in layers. If one layer should fail, another layer will prevent access.

SSH keys come in pairs, one public (think of this as a lock) and one private (think of this as the key). The public key is used to encrypt a message which can only be decoded by the owner of the private key. In this way the machine sending a message encoded using the public key can be sure that the machine responding has the matching private key which can decode the message. The key pair can be used to authenticate or verify that the user is who they claim to be or at the very least that they posses the matching private key.

Lets make a pair of SSH authentication keys we can use to connect to our virtual machines.

The command to create a new key pair is ssh-keygen which creates a key in the ~/.ssh directory. The ~ is a synonym for your home directory (e.g. /home/cgeroux) and the . at the beginning of the directory name indicates that the directory or file is hidden. Hidden files will not be shown by the ls command unless the -a option is used.

Lets check to see if you have a .ssh folder already in your home directory.

$ ls -a ~

.                         .bashrc                  .viminfo
..                        .gitconfig                Desktop
.aptcyg                   .python_history           LauncherFolder
.bash_history             .ssh                      MyDocuments

. and .. directories

Notice that in addition to the hidden directory .ssh we also have hidden directories . and .. as well as others. The . and .. are special directories. The double dot is a shortcut for the parent directory, or the directory which contains your home directory (e.g. /home/). The single dot is a shortcut for the directory its self, your home directory (e.g. /home/cgeroux). The single dot can be used to reference the current directory by starting the path with a . (e.g. ./MyDocuments). Remember when we did cd .. to go up one directory? How about when we talked about relative directories ./Documents/pictures. Both of these use the .. and . shortcuts.

If you do have a .ssh folder, have a look inside.

$ ls ~/.ssh/

id_rsa       id_rsa.pub    id_ed25519     id_ed25519.pub    known_hosts

Notice that the a forward / is used to separate directories. In this case the .ssh directory is inside the home directory ~ (or in this case /home/cgeroux). If you have a pair of files id_rsa and id_rsa.pub or id_ed25519 and id_ed25519.pub you already have a key pair. If you remember the passphrase, if it has one, you can skip the next steps which create a new key pair and just use the key pair you already have.

Have a key pair but forgotten the passphrase?

$ ssh-keygen -y -f ~/.ssh/id_ed25519

Enter passphrase:

Note it will not show characters you type. If you successfully enter your passphrase it will print out the public key as shown.

ssh-ed25519 AAAAC3Nzac1lzdI1mTe5AAaAILWHSMDMhlXIy+C7/dw4a6dUgfZkE3AXng5PDdkYY9Qm user@host

If you instead see something like:

Load key "/home/user/.ssh/id_ed25519": incorrect passphrase supplied to decrypt private key

then you did not correctly type your passphrase. In which case lets rename your existing id_ed25519 and matching id_ed25519.pub to new file names to save key in case you need it later.

$ mv ~/.ssh/id_ed25519 ~/.ssh/old_id_ed25519
$ mv ~/.ssh/id_ed25519.pub ~/.ssh/old_id_ed25519.pub

This way we won’t overwrite the existing key when we create a new one so that if you find you need it later you still have the key.

Creating a key-pair

Only create a new key-pair if you don’t already have a key or you don’t know the passphrase and moved it a side.

To create a key pair run the command

$ ssh-keygen -t ed25519

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/user/.ssh/id_ed25519):

It is asking where to store the keypair, in this case lets just use the default location by pressing the <return> key. Then you will get

Created directory '/home/user/.ssh'.
Enter passphrase (empty for no passphrase):

at which point you should enter a passphrase which will be required to ‘unlock’ the private key. A passphrase is different from a password in that it can contain multiple words. The longer the passphrase the better, though at some point it gets a pain to type frequently.

Enter same passphrase again:

then reneter the passphrase and

Your identification has been saved in /home/user/.ssh/id_ed25519.
Your public key has been saved in /home/user/.ssh/id_ed25519.pub.
The key fingerprint is:
SHA256:WKM/Rx7bBCqPH7DLuXww3xnu0YqL+H1enJHFER1zt/4 user@host
The key's randomart image is:
+---[RSA 2048]----+
|              o=+|
|             . .*|
|        o .   o. |
|       + o . o.  |
|      = S o +  . |
|      oB o.B o  .|
|      o+=o=o*   E|
|     + *o==+     |
|    ..Oo==+      |
+----[SHA256]-----+

now you have a key pair saved in the .ssh folder we can use with the cloud.

To verify lets take a look in the folder

$ ls ~/.ssh/

id_ed25519      id_ed25519.pub

This key pair consists of the private key (the file ~/.ssh/id_ed25519) and a public key (the file ~/.ssh/id_ed25519.pub). You can have a look at the contents of the key files using an editor or a command called cat which just prints the contents of a file to the terminal.

$ cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIIa5jUxyRcjFC+9VVc6Pns6L/FSPs9lWxjPBTRCFHWSl user@host

Your public key can be given out freely, but remember to keep your private key secret.

We will use this public key in the next episode when we create our first virtual machine.

Key file and directory permissions

If the file permissions, specifically of the .ssh directory and the private key, are too open the command we use to connect to a VM will complain about this and not allow us to connect. To see what the current file permissions are run the ls command with the -l option to show the permissions on the files inside the .ssh folder.

$ ls -l ~/.ssh/

-rw-r--r--    1 user  UsersGrp      1766 Mar 31 15:12 id_ed25519
-rw-r--r--    1 user  UsersGrp       396 Mar 31 15:12 id_ed25519.pub

The file permissions are displayed in the far left column. Possible file permissions are r for read, w for write, and x for execute. You will notice the dashes which indicate unset permissions. The first - will be a d if the item is a directory, followed by the three permissions (rwx) for the user who owns the file (in this case the user user). Next are the permissions for the group the file belongs to (in this case UsersGrp) and finally the permissions for everyone else. In this case you can see that the private key id_rsa is actually readable by any user on this computer. Since you should keep your private key private it is good practise to set the permissions on this file to be readable only by the owner of the file. This can be done using the chmod command.

$ chmod og-r ~/.ssh/id_rsa

The above command will remove (-) read (r) permissions for others (o) and users who are members of the file’s group (g). You can also specify changes in permissions for the user which owns the file with u and add permissions by using a + instead of the - as well as specify multiple permissions at once (e.g. chmod u+rwx <file-name>).

Issuing the ls command again shows the changes to the permissions.

$ ls -l ~/.ssh

total 3
-rw-------    1 user  UsersGrp      1766 Mar 31 15:12 id_ed25519
-rw-r--r--    1 user  UsersGrp       396 Mar 31 15:12 id_ed25519.pub

MobaXTerm file permissions

While mobaXterm appears much like a fully functioning Linux terminal there are some limitations, likely due to the fact that it is actually running on Windows. For example this chmod command does not always have an effect. However, on Mac and Linux machines the correct result should be observed.

The .ssh directory should also have restricted permissions so that only the owner has read permissions.

$ chmod og-rx ~/.ssh
$ ls -al ~/

drwxr-xr-x    1 user  UsersGrp         0 Mar 31 15:42 .
drwxr-xr-x    1 user  UsersGrp         0 May 18  2016 ..
drwxr-xr-x    1 user  UsersGrp         0 Jun 11  2016 .aptcyg
-rw-r--r--    1 user  UsersGrp     56801 Mar 31 16:09 .bash_history
-rw-r--r--    1 user  UsersGrp         0 Sep 12  2016 .bashrc
-rw-r--r--    1 user  UsersGrp        83 May 19  2016 .gitconfig
-rw-r--r--    1 user  UsersGrp        20 Sep  1  2016 .python_history
drwx------    1 user  UsersGrp         0 Mar 31 15:42 .ssh
-rw-r--r--    1 user  UsersGrp     10302 Mar  3 11:22 .viminfo
lrwxrwxrwx    1 user  UsersGrp        32 May 18  2016 Desktop -> /drives/C/Users/user/Desktop/
lrwxrwxrwx    1 user  UsersGrp        28 May 18  2016 LauncherFolder -> /drives/C/PROGRA~2/MOBAXT~1/
lrwxrwxrwx    1 user  UsersGrp        33 May 18  2016 MyDocuments -> /drives/C/Users/user/DOCUME~1/

If these permissions are too open the command we use to connect between computers may complain.

SSH File permissions variations

In the case of mobaXterm the ssh command does not require strict permissions, however on Linux machines or Macs the ssh command does require stricter permissions before it will allow you to connect using a private key. In addition depending on the details of your windows operating system and version of mobaXterm you may or may not actually be able to change file permissions within mobaXterm.

Now we have a key pair we can use to connect to our the VM we will create in the next episode.

Key Points

previous episode

next episode