Encryption VI

Encrypting Linux Files

Just as you can encrypt network transmissions between Linux systems
using OpenSSH, you can also use encryption to protect files in the
Linux file system. You can use a wide variety of tools to do this.
Some are open source; others are proprietary. For your Linux+/LPIC-1
exam, you need to know how to use the open source GNU Privacy Guard
(GPG) utility to encrypt files. Therefore, that’s the tool we will use
here. We’ll discuss the following:


• How GPG works
• Using GPG to encrypt files
.


How GPG Works


GNU Privacy Guard (GPG) is an open source implementation of the
OpenPGP standard (RFC 4880). It allows you to encrypt and digitally
sign your data and communications. For example, you can encrypt files
in your Linux file system. You can also encrypt and digitally sign
e-mail messages.


GPG provides a cryptographic engine that can be used directly from the
shell prompt using the


gpg 


command-line utility. It can also be called from within shell scripts or other programs running on the system.


For example, GPG support has been integrated into several popular Linux
e-mail clients such as Evolution and KMail. It has also been
integrated into instant messaging applications such as Psi.


A variety of graphical front ends are available for GPG as well. Some
of the more popular front ends include KGPG and Seahorse. However, for
your Linux+/LPIC-1 exam, you need to know how to use GPG from the
shell prompt, so that’s what we’ll focus on in this chapter.


GPG functions in a manner similar to OpenSSH in that it uses both
asymmetric and symmetric cryptography. 


a) GPG first generates a random symmetric key and uses it to encrypt the message to be transferred.


b) The symmetric key itself is then encrypted using the recipient’s
    public key and sent along with the message that was encrypted using
    the symmetric key.


c) When the recipient receives a message, GPG first decrypts the symmetric key 
    using the user’s private key. GPG then uses the decrypted symmetric key to decrypt 
    the rest of the message.



GPG supports many encryption algorithms, including the following:


Symmetric encryption:
• AES
• 3DES
• Blowfish


Asymmetric encryption:
• Elgamal
• RSA

Hashes:
• MD5
• SHA-1 and -2 
• RIPEMD-160

Digital signatures:
• DSA
• RSA


Now that you understand how GPG works, let’s review how you can use
GPG to encrypt files.


Using GPG to Encrypt Files

To encrypt a file using GPG, do the following:

1. Use GPG to generate your keys. To do this, enter

gpg --gen-key

at the shell prompt. An example is shown here:


      rtracy@openSUSE:~> gpg --gen-key
      gpg (GnuPG) 2.0.22; Copyright (C) 2013 Free Software Foundation, Inc.
      This is free software: you are free to change and redistribute it.
      There is NO WARRANTY, to the extent permitted by law.
      Please select what kind of key you want:
         (1) RSA and RSA (default)
         (2) DSA and Elgamal
         (3) DSA (sign only)
         (4) RSA (sign only)
      Your selection?


2. Select the type of key you want to create. Usually you will use the
default option (1), which uses RSA and RSA. You are prompted to
specify the size of the key, as shown here:


      RSA keys may be between 1024 and 4096 bits long.
      What keysize do you want? (2048)


3. Specify the size of key you want to create. Using the default size
of 2048 bits is usually sufficient. You are prompted to configure the
key lifetime, as shown here:


      Please specify how long the key should be valid.
               0 = key does not expire
            <n>  = key expires in n days
            <n>w = key expires in n weeks
            <n>m = key expires in n months
            <n>y = key expires in n years
      Key is valid for? (0)


4. Specify when the key will expire. As shown in step 3, you can
specify that the key expire in a certain number of days, weeks,
months, or years.


5. Construct your user ID for the key. The first parameter you need to
specify is your real name. The name you specify is very important
because it will be used later during the encryption process. In the
next example, I entered rtracy for my real name:


      GnuPG needs to construct a user ID to identify your key.
      Real name: rtracy


6. When prompted, enter your e-mail address.


7. When prompted, enter a comment of your choosing. You are prompted
to confirm the user ID you have created for the key. An example is
shown here:


       You selected this USER-ID:
           "rtracy <rtracy@openSUSE>"
       Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit?


8. If the information is correct, enter O to confirm the ID. You are
prompted to enter a passphrase for the key, as shown in Figure 18-10.


9. Enter a unique passphrase for the key. After doing so, you are
prompted to perform various actions on the system while the key is
generated. An example is shown here:


       We need to generate a lot of random bytes. It is a good idea to perform
       some other action (type on the keyboard, move the mouse, utilize the
       disks) during the prime generation; this gives the random number
       generator a better chance to gain enough entropy.
       .+++++.++++++++++++++++++++++++++++++.+++++.++++++++++++++++++++++++++++++++
       +++.++++++++++.++++++++++.++++++++++.++++++++++..+++++.++++++++++>++++++++++
       ...................................>+++++............................<+++++.
       ................................>+++++...........<+++++.......+++++


10. Move the mouse, type characters on your keyboard, or open and
close your optical disc drive door. GPG uses these actions to generate
random numbers to create your key. Be aware that if you’re not doing
enough, you’ll be prompted to increase your activity to generate
enough entropy to create the key. An example is shown here:


       Not enough random bytes available.  Please do some other work to give
       the OS a chance to collect more entropy! (Need 137 more bytes)



At this point, your key pair has been generated! The key files are
stored in the


~/.gnupg 


directory in your user’s home directory. The following files are created in this directory:

• secring.gpg   This file is the GPG secret keyring.

• pubring.gpg   This file is the GPG public keyring.

• trustdb.gpg   This file is the GPG trust database.




Before going any further, you should seriously consider creating a
backup of your private key in case it gets corrupted. This is very
important because if you encrypt files with your key pair and then
lose your key, you will never be able to decrypt them. They are toast!
Even if you re-create  your key pair, you will not be able to decrypt
the files because they were encrypted with a different key pair.



To create a backup of your gpg key pair, enter



gpg --export-secret-keys --armor key_owner_ email_address > filename.asc



at the shell prompt. This is shown in the following example:


gpg --export-secret-keys --armor rtracy@openSUSE >
rtracy-privatekey.asc rtracy@openSUSE:~> ls
addnum firstnames mytestfile.txt rtracy-privatekey.asc


For security reasons, you probably shouldn’t leave this file on your
hard disk. Instead, consider burning it to an optical disc or copying
it to a USB flash drive and locking it away in a file cabinet
somewhere. This will allow you to restore your private key should the
original copy on the hard drive get mangled.


You can now use your key pair to encrypt files and messages. For
example, if you wanted to encrypt a file in your Linux file system,
you would do the following:


1. At the shell prompt, enter

gpg –e –r key_user_name filename

In the example shown here, I’m encrypting the mytestfile.txt file
using the key I generated previously. The –e option tells gpg to
encrypt the specified file. Remember that I specified a key username
of rtracy when I created the key user ID, so that’s what I entered
here.

      rtracy@openSUSE:~> gpg -e -r rtracy mytestfile.txt

2. At the shell prompt, use the ls command to view the new encrypted
version of the file gpg created. The original file is left intact.


The new file will have the same filename as the original file with a“.gpg” extension added. 


In the example here, the name of the new file is mytestfile.txt.gpg. 


In Figure 18-11, the differences between the
original file and the encrypted file are shown.


Once the file has been encrypted, it can then be decrypted using the
gpg command. The syntax is



gpg --output output_filename --decrypt encrypted_filename



For example, to decrypt  the mytestfile.txt.gpg file I created
earlier, I would enter



gpg --output mytestfile.txt.decrypted --decrypt mytestfile.txt.gpg



This is shown in the example here:



rtracy@openSUSE:~> gpg --output mytestfile.txt.decrypted --decrypt mytestfile.txt.gpg


You need a passphrase to unlock the secret key for

user: "rtracy (<rtracy@openSUSE>"
2048-bit RSA key, ID FB8BF16C, created 2015-01-24 (main key ID 9DF54AB2)
gpg: encrypted with 2048-bit RSA key, ID FB8BF16C, created 2015-01-24
      "rtracy (<rtracy@openSUSE>"
rtracy@openSUSE:~> cat mytestfile.txt.decrypted
This is a text file that I wrote.
rtracy@openSUSE:~>


At this point, you are able to encrypt and decrypt files on your local
system.


But what do you do if you want to be able to exchange
encrypted files with someone else and both of you be able to decrypt them? 


To do this, you must exchange and install gpg public keys on your systems. There are two ways to do this.


The first option is to copy your public keys to a public key server on
the Internet. This is done by entering


gpg --keyserver hkp://subkeys.pgp.net --send-key key_ID



at the shell prompt. Notice that this command requires you to know the
ID number associated with your gpg public key. This number is actually
displayed when you initially create your gpg key pair, but if you’re
like me, you probably didn’t take note of it. That’s not a problem
because you can generate it again from the command line. To do this,
enter


gpg --fingerprint key_owner_email

An example is shown here:

rtracy@openSUSE:~> gpg --fingerprint rtracy@openSUSE > key_ID.txt
rtracy@openSUSE:~> cat key_ID.txt
pub  2048R/9DF54AB2 2015-01-24
     Key fingerprint = AF46 4AB3 1397 B88E BC6A FBDA 465F 82C4 9DF5 4AB2
uid    rtracy       <rtracy@openSUSE>

sub  2048R/FB8BF16C 2015-01-24




In this example, I actually saved the output from the command to afile named key_ID.txt to keep it handy, but this is optional. The ID
number of the key is contained in the first line of output from the
command. Note that I’ve bolded the number needed.


Once you have the ID number, you can then copy your gpg public key to
a public key server on the Internet. Using the preceding information
for my system, I would enter



gpg --keyserver hkp://subkeys.pgp.net --send-key 9DF54AB2



at the command prompt.




This option works great if you want to be able to exchange keys with a
large number of other users.





However, if you are only concerned about doing this with a limited number of people, you can also just directly exchange keys between systems.


To do this, you (and the other users) can export your public keys and
send them to each other. To do this, you enter



gpg --export --armor key_owner_email > public_key_filename



at the shell prompt.



For example, to export the public key to a file named gpg.pub from the
key pair I created earlier, I would enter the following:


rtracy@openSUSE:~> gpg --export rtracy@openSUSE > gpg.pub




Each user can then copy their key file to the other users. For
example, if I wanted to send my key to the student user account on
another Linux host named fedora, I would enter the following:

rtracy@openSUSE:~> scp gpg.pub student@fedora:

Once this is done, each user should import the other users’ public
keys into their GPG keyring using the



gpg --import public_key_filename



command at the shell prompt. In the example shown next, I first used
scp to copy the public key file from the openSUSE system to the fedora
system. I then used gpg to import the public key.



[student@fedora ~]$ gpg --import gpg.pub
gpg: key 9DF54AB2: public key "rtracy <rtracy@openSUSE>" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
[student@fedora ~]



Remember, each user needs to repeat this process. Then they can use
each other’s gpg keys to encrypt and decrypt files.




You can view the keys in your GPG keyring using the


gpg --list-keys



command, as shown in the following example:

[student@fedora ~]$ gpg --list-keys
/home/student/.gnupg/pubring.gpg
--------------------------------

pub   2048R/9DF54AB2 2015-01-24
uid   rtracy <rtracy@openSUSE>
sub   2048R/FB8BF16C 2015-01-24
[student@fedora ~]$



In this example, you can see that the public key I created earlier on
openSUSE is now imported into the student user’s GPG keyring on
fedora.




The keyring file itself is located in the 


~/.gnupg/ 


directory within my home directory and is named 


pubring.gpg


NOTE

The


gpg.conf 


file is also located in the 


~/.gnupg 


directory. You can use this file to customize the way gpg works on your system.


I would then need to do the same thing in reverse. I should import the
public key from the student user on the fedora system to my system
(openSUSE).


With the public keys imported, we could exchange encrypted files and be able to decrypt them. 

The syntax for doing this is



gpg --output output_filename --symmetric encrypted_filename




For example, if I sent the mytest- file.txt.gpg encrypted document
from my openSUSE system to my fedora system, I would enter the
following command to decrypt it



gpg --output mytestfile.txt.decrypted --symmetric  mytestfile.txt.gpg


When I do, I am prompted to enter the passphrase I assigned to the
private key when I initially generated it. Once this is done, the
decrypted version of the file is created and is accessible to the
local user.



Before we end this chapter, we need to discuss the topic of key
revocation. From time to time, you may need to revoke a key, which
withdraws it from public use. This should be done if the key becomes
compromised, gets lost, or if you forget the passphrase associated
with the key.


NOTE     Forgetting the passphrase associated with the key pair is a very
common problem that results in key revocation.



To revoke a key, you create a key revocation certificate. As a best
practice, you should create a key revocation certificate immediately
after initially creating your key pair. This is done in case something
gets corrupted and the revocation certificate can’t be created should
it be required for some reason later on. Here’s a key thing to
remember: creating the key revocation certificate doesn’t actually
revoke the key pair. Only when you actually issue the key revocation
certificate does the key get revoked. Basically, you create the key
revocation certificate and save it in a secure location just in case
it’s needed later.



To create (not issue) the key revocation certificate, enter



gpg --output revoke.asc --gen-revoke key_ID



at the shell prompt. Remember, you can use the


--fingerprint option


with the gpg command to view the key ID number. In the example that
follows, I create a key revocation certificate for the gpg key pair I
generated for the student user on my fedora system:



[student@fedora ~]$ gpg --fingerprint student@fedora
  pub
2048R/899AB9E6 2015-01-24
Key fingerprint = A469 942C F5C9 555A B4A4 F975 1B3A CB26 899A B9E6
uid
sub
[student@fedora ~]$ gpg --output revoke.asc --gen-revoke 899AB9E6
sec  2048R/899AB9E6 2015-01-24 student <student@fedora>
Create a revocation certificate for this key? (y/N) y
Please select the reason for the revocation:
  0 = No reason specified
  1 = Key has been compromised
  2 = Key is superseded
  3 = Key is no longer used
  Q = Cancel
(Probably you want to select 1 here)
Your decision? 1
Enter an optional description; end it with an empty line:
> This key has been compromised
>
Reason for revocation: Key has been compromised
This key has been compromised
Is this okay? (y/N) y
You need a passphrase to unlock the secret key for
user: "student <student@fedora>"
2048-bit RSA key, ID 899AB9E6, created 2015-01-24
ASCII armored output forced.
Revocation certificate created.
Please move it to a medium which you can hide away; if Mallory gets
access to this certificate he can use it to make your key unusable.



It is smart to print this certificate and store it away, just in case
your media become unreadable.  But have some caution:  The print system of
your machine might store the data and make it available to others!

Notice in this example that I had to specify a reason why the key is
to be revoked along with a more detailed description. I also had to
provide the passphrase that was used when the key pair was originally
created. Also notice the warning message at the end of the command
output. You probably should avoid keeping the key revocation
certificate on your system’s hard disk. Instead, burn it to the same
optical disc or copy it to the same flash drive as your key pairbackup and lock it away! If someone were to get a hold of this file,
they could revoke your certificate without your knowledge or consent,
which would be a bad thing.


TIP     The output of the command says to print out the key revocation
certificate. I think that is a cumbersome way to archive it. If you
ever needed to issue it, you would have to type the revocation
certificate in manually.


Yuck! I much prefer copying it to a flash drive that I keep locked in a cabinet. Don’t forget to delete the file off the hard disk, no matter what archival mechanism you choose to use.


So what should you do if your certificate actually does get
compromised and you end up needing to revoke it? The process is
actually pretty easy. All you have to do is import the revocation
certificate in the same manner we talked about for standard
certificates. You enter gpg --import revocation_certificate_filename
at the shell prompt. An example is shown here:


[student@fedora ~]$ gpg --import revoke.asc
gpg: key 899AB9E6: "student <student@fedora>" revocation certificate imported
gpg: Total number processed: 1
gpg:    new key revocations: 1
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u


Once this is done, you can verify that the key was revoked by entering



gpg --list-keys key_ID 


at the shell prompt. You should see that the revoked key is now gone from your keyring.
If you used the manual method discussed earlier in this chapter to distribute your public
key, you must import the key revocation certificate on any other
systems where your public key was imported.


If you are using a public key server on the Internet to distribute
your keys to other users, you would need to issue the key revocation
certificate there as well. Enter 



gpg --keyserver public_key_server_URL --send key_ID 



at the shell prompt. This lets everyone who is using your public key know that the key has been 
compromised and should no longer be used.




















LX0-104 Exam Objectives (X)

Encryption IV

Tunneling Traffic Through SSH

One of the key security issues you must deal with as a system
administrator is the fact that many commonly used network protocols
transfer information as clear text. Good examples of this are the POP3
and IMAP daemons we discussed in the preceding chapter. We noted that
for your Linux MTA to download e-mail messages to client systems, you
must first enable either your POP3 or IMAP daemon via xinetd. Once
done, end users can use an e-mail client to connect to the MTA and
download their mail using the appropriate protocol. The problem,
however, is the fact that both of these daemons transfer data as clear
text by default. That means the usernames and passwords users send to
authenticate to the MTA are sent as clear text along with all the con-
tents of their e-mail messages. This allows anyone with a sniffer to
capture packets and view the contents of the transmissions.



The good news is SSH can be used to encrypt clear-text traffic by
tunneling it through an SSH connection. When client software for the
tunneled protocol (such as an e-mail client using POP3) establishes a
connection with the local SSH client, the traffic is encrypted using
SSH and tunneled through to the SSH server. On the SSH server end, the
traffic is decrypted and then forwarded to the appropriate target
service (in this case, the POP3 daemon). This is great, because the
information is encrypted before being transmitted, even though the
original protocol (in this case, POP3) doesn’t support encryption.




Let’s walk through an example of how you can use SSH to tunnel POP3 traffic:



1. Make sure the ssh client is installed on the local system where the
   e-mail client will run.


2. Make sure the sshd daemon is installed and running on the POP3 server.


3. Ensure IP port 22 is open on the server where sshd is running.


4. On the system where sshd is running, switch to root and edit the
 


  /etc/ssh/sshd_config 



   file.


5. Locate the AllowTcpForwarding parameter, uncomment it if necessary,
   and then set it to a value of yes. An example is shown here:



    AllowTcpForwarding  yes



6. Save your changes to the file and exit the editor.


7. Restart the sshd daemon by entering systemctl restart sshd at the
   shell prompt (as root).



8. Switch to the client system.



9. Create a local ssh tunnel from a local high IP port (in this
   example, port 2345) to port 110 on the POP3 server using the following
   command (enter the remote user’s password when prompted):



    ssh -f -N -L 2345:pop3_host_address:110 user_name@pop3_host_address




   The options specified in this command do the following:



   • –N and –f 

     Tell ssh not to execute a command remotely on the server
      and to run in the background after prompting for the remote user’s
      password


   • –L 

      Specifies three things:

      • The local port to be used for the client end of the tunnel (in
        this case, 2345)

      • The hostname or IP address of the remote POP3 server

      • The port on the remote server that will be used for the server
        end of the tunnel (in this case, 110)



   You don’t have to use port 2345. You can use the same port on both
   ends if desired. However, be aware that you will need to switch to the
   root user if you want to use a port number less than 1024 on the
   client side of the tunnel. These are called privileged ports.



10. With the tunnel established, configure the local e-mail client
    program to retrieve mail from the local system on the port you
    configured for the client end of the SSH tunnel. In this example, you
    would configure it to get mail from the local system’s IP address on
    port 2345. An example of how to do this with the Evolution e-mail
    client is shown in Figure 18-6.


    Note that I used the hostname of the local host, not the POP3 server, in the Server field.
    I also added the port number of the workstation end of the tunnel to the end of the
    hostname.




At this point, when the client uses the POP3 protocol to download new
messages, the SSH client on the local system will encrypt the request
and forward it to the SSH server through the SSH tunnel you
established. The SSH server will receive the request, decrypt it, and
then pass the data on to the local port 110, where the POP3 daemon is
listening. The cool thing about this process is that it is completely
transparent to the e-mail client software. As far as it’s concerned,
it’s retrieving e-mail from a local POP3 server.



You can test the tunnel you created using the telnet command from the
client end of the tunnel. The syntax is


telnet localhost client_tunnel_port


Here’s an example:



telnet localhost 2345



When you do this, you should see a connection established with the remote system where the POP3 daemon is running. An example is shown in Figure 18-7.




You can also tunnel your X server traffic to remote X clients using an SSH connection. This is important because unencrypted X traffic provides an attacker with a gold mine of information that he or she can use to compromise your systems.






To configure a remote X client without encryption, you can use the
following procedure:


1. On the remote X client, enter



   xhost +X_server_hostname



   This tells the client to accept connections from the X server.



2. On the X server, enter



   DISPLAY=X_client_hostname:0.0



   and then enter



   export DISPLAY



   This tells the X server to display its output on the remote X client.




3. From the X client, use the ssh client to access the shell prompt on
   the X server and then run the graphical application you want displayed
   on the X client. For example, you could enter gedit at the shell
   prompt to remotely display the gedit text editor. You could also enter
   office at the shell prompt to remotely display the OpenOffice.org
   suite.








This procedure works, but all the X traffic is transmitted
unencrypted. This isn’t good. Instead, you should use SSH to tunnel
the X server traffic between the X server and the X client. You can do
this using one of the following options:



• Use the –X option with the ssh client program.


• Set the 


ForwardX11 


option to a value of 


yes


in the


 /etc/ssh/ssh_config 


  file on the X client system.




Once this is done, you then need to set the


X11Forwarding 


option to



yes 



in the



/etc/ssh/sshd_config 



file on the X server system.












LX0-104 Exam Objectives (X)

Encryption III

Configuring OpenSSH


To use ssh, you must first install the openssh package on your system
from your distribution media. This package includes both the sshd
daemon and the ssh client. OpenSSH is usually installed by default on
most Linux distributions. You can use the package management utility
of your choice to verify that it has been installed on your system.



The process of configuring OpenSSH involves configuring both the SSH
server and the SSH client.


You configure the sshd daemon using the



/etc/ssh/sshd_config 



file.



The ssh client, on the other hand, is configured using the



/etc/ssh/ssh_config file 



or the



~/.ssh/ssh_config




file.





Let’s look at configuring the SSH server (sshd) first. There are many
directives within the



/etc/ssh/sshd_config 



file. The good news is that after you install the openssh package, the default parameters work
very well in most circumstances. To get sshd up and running, you shouldn’t have to make many changes to the sshd_config file. Some of the more useful parameters in this file include those shown in Table 18-1.

The ssh client on a Linux system is configured using the



/etc/ssh/ssh_config



file.





The



/etc/ ssh/ssh_config 




file is used to specify default parameters for all users running ssh on the system.



A user can override these defaults using the



~/.ssh/ssh_config 




file in his or her home directory. The precedence for ssh client configuration
settings are as follows:





1. Any command-line options included with the ssh command at the shell prompt


2. Settings in the ~/.ssh/ssh_config file


3. Settings in the /etc/ssh/ssh_config file






As with the sshd daemon, the default parameters used in the ssh_config
file usually work without a lot of customization. However, some of the
more useful parameters that you can use to customize the way the ssh
client works are listed in Table 18-2.

Of course, before you can connect to an SSH server, you must open up



port 22 


in the host- based firewall of the system where sshd is
running. For example, in Figure 18-4, the YaST Firewall module has
been loaded on a SUSE Linux Enterprise Server 10 system and configured
to allow SSH traffic through.






After configuring your firewall, you can load the ssh client on your
local computer and connect to the sshd daemon on the remote Linux
system by entering




ssh –l user_name ip_address




TIP


Don’t forget the –l parameter. If you don’t, the SSH client will
attempt to authenticate you to the remote system using the same
credentials you used to authenticate to the local system. If the
credentials are the same onboth the client and server systems, you’ll
still be able to authenticate. But if they aren’t, you won’t be able
to authenticate.






For example, if I wanted to connect to a remote Linux system with a
hostname of fedora (which has an IP address of 10.0.0.85) as the user
student using the ssh client on a local computer system, I would enter



ssh –l student fedora 



at the shell prompt. This is shown in Figure 18-5.






Notice in Figure 18-5 that I was prompted to accept the public key
from the fedora host because this was the first time I connected to
this particular SSH server. Once done, I was authenticated to the
remote system as the student user (notice the change in the shell
prompt). At this point, I have full access to the shell prompt on
fedora and I can complete any task that I could if I were sitting
right at the console of the remote system. To close the connection, I
just enter exit at the shell prompt.









LX0-104 Exam Objectives (X)

Encryption II

How OpenSSH Works


OpenSSH provides the functionality of Telnet, rlogin, rsh, rcp, and
FTP, but it does so using encryption. To do this, OpenSSH provides the
following encryption-enabled components:



• sshd   This is the ssh daemon that allows remote access to the shell prompt.

• ssh  This is the ssh client used to connect to the sshd daemon on
another system.

• scp  This utility can be used to securely copy files between systems.

• sftp  This utility can be used to securely FTP files between systems.

• slogin  This utility can also be used to access the shell prompt remotely.





To establish a secure connection, OpenSSH actually uses both
private/public key encryption along with secret key encryption. First,
the SSH client creates a connection with the system where the SSH
server is running on


IP port 22


The SSH server then sends its publickeys to the SSH client. The SSH server uses the
host key pair to store its private and public keys, which identify the host where the SSH
server is running. The keys are stored in the following files:




• Private key /etc/ssh/ssh_host_key

• Public key /etc/ssh/ssh_host_key.pub




The client system receives the public key from the SSH server and
checks to see if it already has a copy of that key. The SSH client
stores keys from other systems in the following files:


• /etc/ssh/ssh_known_hosts

• ~/.ssh/known_hosts




By default, if it doesn’t have the server’s public key in either of
these files, it will ask the user to add it. 


Having done this, the client now trusts the server system and generates a 256-bit secret
key.


It then uses the server’s public key to encrypt the new secret
key and sends it to the server. 


Because the secret key was encrypted with the public key, the server can decrypt it using 
its private key.

Once this is done, both systems have the same secret key and can now
use symmetric encryption during the duration of the SSH session.


The user is presented with a login prompt and can now authenticate
securely because everything she types is sent in encrypted format.




NOTE  

In SSH version 2, several things are a little different. First of
all, the host key files used on the server are different. The


/etc/ssh/ssh_host_rsa_key 


and



/etc/ssh/ssh_host_dsa_key 



files are used (along with their associated public keys) instead of
/etc/ssh/ssh_host_key. The key pair used depends on
which encryption mechanism (RSA or DSA) the client and server have
been configured to use. In addition, the secret key is not actually
transmitted from the client to the server system. A Diffie-Hellman key
agreement is used instead to negotiate a secret key to be used for the
session without actually sending it over the network medium.




After this secure channel has been negotiated and the user has been
authenticated through the SSH server, data can be securely transferred
between both systems.







LX0-104 Exam Objectives (X)

Encryption I

Encrypting Remote Access with OpenSSH

In the early days of UNIX/Linux, we used a variety of tools to
establish network connections between systems. You could access the
shell prompt of a remote system using Telnet, rlogin, or rshell. You
could copy files back and forth between systems using rcp or FTP.
However, these utilities had one glaring weakness. Network services
such as Telnet, rlogin, rcp, rshell, and FTP transmit data as clear
text. Anyone running a sniffer could easily capture usernames and
passwords along with the contents of the transmissions.



For example, suppose I remotely accessed my Linux system via Telnet.
After authenticating to the remote system, I decided that I needed to
switch to root using the su command to complete several tasks. If
someone were sniffing the network wire while I was doing this, they
would be able to easily grab the following information:


• My username and password

• The root user password



This is not a good thing! The attacker would have everything he needs
to gain unfettered access to my Linux system.



To prevent this from happening, you can use the OpenSSH package to
accomplish these same management tasks using encryption. In this part
of the chapter, you will learn how to use OpenSSH. The following
topics are addressed:



• How OpenSSH works

• Configuring OpenSSH

• Tunneling traffic through SSH

• Configuring SSH to use public key authentication














LX0-104 Exam Objectives (X)