Since managing network computers will often mean you'll be spending plenty of time transferring resources back and forth among machines, and logging in and out of remote shell sessions, it's hugely important that you should make sure that you're not exposing passwords and sensitive data in the process. The best way to address this need is through encryption, which uses complex algorithms to convert your plaintext data into an unreadable mess of apparently random characters. For all practical purposes, the only way to decrypt such data is by using software that can apply the original algorithm in reverse. Linux employs a program called OpenSSH to ensure that remote communication is properly encrypted. As you've seen many times in the series, you initiate OpenSSH remote shell sessions using ssh, followed by the account name and address of the machine you want to access. By default, you will now enter the password for the user account on the host machine, then you'll be in. As you'll see in just a minute, OpenSSH can also be configured to permit passwordless remote sessions. And in fact, from a security perspective, those are much preferred. But let's first learn a bit about how OpenSSH actually works.

When a login session opens, the ssh agent program launches to hold all private keys that will be used for public key authentication. The encryption is controlled by files in the etc/ssh directory. Here, we can see eight ssh key files which are really four pairs of host key files. One of each pair is public, recognizable of course through their .pub extension, and the other is private. We'll talk more about the differences between public and private files a bit later.

Each of the four pairs is built using a different encryption algorithm: DSA, RSA, Ed25519 and ECDSA. DSA stands for Digital Signature Algorithm. And RSA are the first letters of the names of the three MIT researchers who created the particular algorithm: Rivest, Shamir and Adleman.

It is these keys that will be used to authenticate and encrypt all incoming traffic from clients also using OpenSSH.

These keys, by the way, all use the SSH protocol 2. The way your machine will be allowed to host remote client sessions is controlled by the sshd_config file.

We can see that the file allows you to control many configuration details, including the session port, which is currently set to the SSH default port of 22.

Changing that value to a very high port, like say, 45123, would make unauthorized access to your system that much harder. But you'd have to make sure that all legitimate clients were configured properly. The file also points to four host keys we saw just before, and defines other behavior like logging and authentication. Since you could also use this machine as a client to access a different machine, OpenSSH will control client behavior. This time through the ssh_config file. The ssh_config file controls a long list of behavior variables, most of which are currently not enabled. Let's review. OpenSSH encrypts data passing between machines using key pairs stored in the etc/ssh directory.

SSH protocol 2 algorithms include RSA and DSA, with RSA being the stronger. SSH server or host behavior is controlled by the sshd_config file, while SSH client behavior is managed through the ssh_config file.

Now let's explore the way OpenSSH allows remote sessions that work between trusted machines without the need to enter passwords each time.

Besides the key pairs we've already seen in etc/ssh, OpenSSH can be told to create different key pairs in a /.ssh directory, in a user's home directory.

This machine doesn't yet have any keys, or even a .ssh directory. So let's create some. First of all, we should make sure that OpenSSH is properly installed. Now we'll run ssh-keygen to automatically generate a new key pair.

We'll create an OpenSSH 2 key pair using the RSA encryption algorithm. We could specify our own filename, or simply go with the default. For significantly stronger protection, we can add a passphrase to protect against the possibility of somebody stealing your private key, and then gaining access to your host from his own machine. Note however that if you do use a passphrase, you might want to avoid having to type it for each login, which kind of defeats part of the purpose of passwordless logins.

By providing your passphrase just once per session to the SSH agent program by way of ssh-add, you can both maintain control over your private keys, and simplify your login sessions.

You could also use DSA or not specify any standard at all, which would by default, create keys compliant with the SSH protocol version 1.

Specifying RSA or DSA will generate keys using the stronger protocol 2. Overall, the protocol 2 RSA is usually considered a more efficient and in some ways, stronger standard.

Notice how we don't run keygen as sudo. Note that one file of each of these pairs has a .pub extension, which as you can guess, stands for public. Note also that the public keys permit other uses to read them, while the private keys are accessible only to their owner.

This is because you're going to copy the contents of the public key to be stored in the authorized keys file in the hidden SSH directory on the host machine. By host, we mean the machine into which you plan to login from a remote location. But the private key will remain on your client machine and must be carefully protected as it effectively contains all the keys to your castle.

Now that we've got a new pair, we'll have to copy the public key to the host server we want to access remotely.

There are all kinds of ways to do this, but the main thing is to be absolutely sure that you don't make any changes to the file contents along the way.

We use SCP, Secure Copy, which works securely through the OpenSSH package. From the same directory that holds the file, run SCP, the filename, the login address, and the directory on the host machine where you'd like the file to go. SCP by the way, works on top of our OpenSSH infrastructure and takes advantage of both its encryption and connectivity.

Now you'll need to ssh into the server, still using the less secure password access method just one last time.

Let's view the key file we've just copied. CD to the /.ssh directory. Confirm that an authorized keys file exists.

And add the contents of the key file to the authorized keys file. Now. just to make sure it's set right, we'll restrict permissions for the file to access only by its owner.

We'll log out and try logging in again to make sure we're not asked for a password. I'll exit the host so we can take a look at the known host file in our /.ssh directory where you can see a record of the machine we've just visited.

Should any of these details change in the future, and we try to log in again, we'll be warned of the change, and advised to update this file if you want to proceed.

Let's review. Key pairs to control passwordless remote shell sessions are usually kept in the /.ssh directory in a user's home directory.

Key pairs for passwordless access are created by ssh-keygen and if desired, defined using the -t argument.

If you create .ssh key pairs with the passphrase, you can pass the phrase just once to SSH agent using ssh-add.

The public key is added to the authorized keys files on the host machine while the private key is kept safely on the client. The known host file on the client machine contains references to each host machine that you've accessed using passwordless key pairs.