Hi. This is going to be the very last video in our LPIC-1 Certification series so we're going to wrap up just a few remaining encryption related details, and then say goodbye. We'll talk about SSH tunnels, GPG file encryption, and using SSH key pairs on Amazon's AWS. First of all, we're going to use what we've learned about SSH connections to create and use an SSH tunnel, that is, once you've got a live SSH session between two machines, you can use the connection to carry other functions. For instance, suppose you need to securely open a GUI program on a remote computer. Perhaps someone you're working with is having trouble configuring his or her own desktop and you'd like to help. To do this, we'll have to make sure that two simple settings in the ssh_config files on both our host and client machines are set to allow X11 connections. On the host machine, or in other words, the machine into which we will be logging for our remote session, we'll open up the etc/ssh/sshd_config file to make sure that X11 forwarding is set to yes, which happens to be true already. Now on the client machine, meaning the computer from which we'll launch the SSH session, we'll edit the etc/ssh/sshd_config file so that the value of the ForwardX11 option is yes.

Now let's create a special XSSH session. We're in. So let's see if we can open a GUI program, say, gedit.

It works. Besides using encryption to protect the data transferred back and forth in the process of running remote sessions, we can also encrypt files and messages sent between systems. In this case, however, the tool of choice is GPG, which stands for GNU Privacy Guard. Here's how it works. GPG will generate a random symmetric key that it uses to encrypt a message you'd like to transfer.

The symmetric key is itself then encrypted using the recipient's public key, and then sent with the encrypted message. When the recipient gets the message, GPG will decrypt the symmetric key using his private key. GPG then uses that decrypted key to decrypt the actual message.

Let's generate some GPG keys using gpg --gen-key. We'll first be asked to select a key type. We'll stick with the default value. The default of 2048 bits for the key length is also fine for us.

We are now asked to configure how long the key should be allowed to remain valid. Using 0 will allow it to remain indefinitely. Since it's usually not a great idea to create a key without any limits, GPG will ask if you're sure you want it done that way in this case.

We'll add a username, email, and a comment; all of which will be used as part of the key creation process.

Next, we'll add a passphrase, and of course, we'll be very careful not to forget this phrase. Finally, we'll be asked to generate as much random noise as possible.

I'll open a second session on his virtual machine and create some serious but useless busywork using find and xargs.

Eventually that will satisfy GPG's needs and we'll have our new keys stored happily in the hidden .gnupg directory.

Now that we have our GPG keys, we can use them along with the username and password we created earlier to encrypt the file. As you can see, gnupg has created a new file with the gpg extension. We could now use any normal method to copy the file as an email attachment, for instance, without having to worry about security. Let's see how we might decrypt our encrypted file.

We'll run GPG with the --output argument, create an easily recognizable name for the output file, and use the name of our GPG file as a value for decrypt. We'll enter the passphrase we specified when we created the keys, and we'll have our new decrypted version of the file. Of course, since the original happens to be sitting in the same directory in our case, that's not all that useful. But you can see how it would be if we'd received only the encrypted file through an Internet transfer. So that a real recipient can decrypt files you send them, we'll have to know how to export and then import public keys.

To export your key, use gpg --export and the name you gave your key. Then pipe the key to a new file that should end with the .pub extension.

When he gets it, the recipient will have to import the key into his own GPG installation using gpg --import and the name of the file.

Of course, we're not going to do that here since the key is already a part of our set. But this is how you would do it on a recipient system. We can view all of the public keys on a system using --list-keys.

Finally, there may be times when you'll need to revoke existing GPG keys. Perhaps, for instance, a server where the public key has been compromised, and you can't be sure that the key hasn't fallen into unfriendly hands.

On a simple level, revoking is quite straightforward. You simply run --gen-revoke, followed by your key ID.

This will print some ASCII text which you should copy into a new file. This is something you can do at the time you create your keys in the first place.

In fact, considering that your own machine can be compromised, stolen or destroyed, it's probably not a bad idea to keep your revoke text file somewhere safe. When you need to revoke the key, run gpg --import using the revoke text file as input.

Now, one last time, let's review. To enable X11 connections, the value of the X11 forwarding setting in the host's etc/ssh/sshd_config file must be yes, and the value of ForwardX11 in the client's etc/ssh/ssh_config file must also be yes.

You open an xssh session using ssh -x. You generate GPG keys using gpg --gen-key supplying a username, a passphrase, and lots of noise in the background to provide food for the randomizing process.

You can decrypt files using gpg --output filename and --decrypt filename.gpg. You can export a key using gpg --export piping the output to a new file, and import a key to your system using gpg --import.

Gpg --list-keys will display the keys on your system. Gpg --gen-revoke followed by a key ID will output text that can then be used to revoke a key.

And gpg --import can be used to actually revoke a key. AWS has their own system for managing SSH key pairs.

From the EC2 dashboard, click on Key Pairs, then on Create Key Pair. Give your pair a name and click Create, and AWS will create the file with a .pem extension, and automatically offer you the option of opening or saving the file.

You might want to save it to your home directory so it will always be immediately available whenever you open your terminal.

You must edit the public key's file permissions so that no one but the owner has access. If you don't do this, you won't be able to connect. Once you're ready to access a resource, you use ssh followed by -i and the name of the .pem file, and then the resource address.

Bear in mind that AWS key pairs are tied to the region in which they are created. If you'd like to use a key pair that was created in one region to access, say, an EC2 instance that's in a different region, it won't work.

So that's it. We really hope that this series of courses on Linux Server Administration has taught you a lot about the beauty and function of Linux, and has prepared you for both the LPIC-1 exams and for a career in Linux System Administration.