Using Encryption CHAPTER. In this chapter, you will learn about How encryption works Encrypting remote access with OpenSSH Encrypting Linux files

Transcription

1 Using Encryption 18 CHAPTER In this chapter, you will learn about How encryption works Encrypting remote access with OpenSSH Encrypting Linux files As mentioned at the beginning of the preceding chapter, information security is a key issue in nearly every organization. If it isn t, it should be. Twenty years ago, we in the IT industry just didn t worry all that much about information security. That s because society in general didn t worry all that much about information security. Let me give you two examples. First, when I was an undergraduate in the late 1980s and early 1990s, it was common for my professors to post exam scores in the hallway outside their office using students Social Security numbers. I chuckle when I recall the reason why; it was to protect students privacy. Heaven forbid we should associate a name with a test score, let s just use their SSNs! State and federal governments were not immune to this type of practice either. Again, when I was in college, my home state used your Social Security number as your driver s license number. They printed it right on the license itself. Therefore, every time you used your driver s license for ID, you were revealing your SSN. What s worse, we used checks a lot more back then than we do now. Guess what every store clerk wrote on each check? Yep, they recorded your driver s license number. That means each check I wrote in college had my SSN and my bank account number recorded on it. Sheesh! Today, we think doing something like this would be crazy. Back then, we didn t think anything of it. That has all changed in today s security-conscious world. Folks who wear black hats have figured out that a minimal amount of information can yield huge profits, and they will stop at nothing to get it. As a result, we who wear white hats have to be almost obsessive about information security. Information security is focused on protecting the valuable electronic information of organizations and users. Thus, the demand for IT professionals who know how to secure networks and computers is at an all-time high. As a Linux system administrator, you need to be very aware of the security issues affecting your implementation. In the preceding chapter, we spent some time looking at several policies and practices you can put in place to help secure your systems. In this chapter, we re going to expand on what you learned in the last chapter and discuss how you can use encryption to increase the security of your Linux systems and network. 709

2 LPIC-1/CompTIA Linux+ Certification All-in-One Exam Guide 710 TIP Information security is a huge topic that we can t adequately address in this book. I highly recommend that you enhance your knowledge by getting your Security+ certification from CompTIA. The IT world has become the modern equivalent of the Wild West from American history. You need to know how to thoroughly protect your data from malicious black hats! Let s begin by discussing how encryption works. How Encryption Works Hearken back with me, if you will, to your elementary school days. Did you ever pass notes to your friends? I know that in the modern era of mobile devices and text messaging this may seem archaic; but when I was a kid, notes were a vital means of communication at school. After all, you had important business to conduct, right? If your school was like mine, these extracurricular forms of communication were strictly forbidden in class. If a teacher intercepted a poorly handled note pass, you could be sure it would be read in front of the class, which could be a fate worse than death (especially if the note contained information about who currently likes whom). To prevent this, my buddies and I developed codes to encrypt our notes. If one of them was intercepted, we could rest assured that the teacher wouldn t be able to read it to the rest of the class. As fourth graders, our encoding mechanisms were primitive. For the most part, we used two codes. The first one involved skewing the alphabet down a letter or two, as shown here: ZABCDEFGHIJKLMNOPQRSTUVWXY ABCDEFGHIJKLMNOPQRSTUVWXYZ NOTE This simple encryption technique is called a letter shift. We would use the bottom line for the clear text and the top line for the cipher text. For example, the clear text JAKE LIKES PAM would come out IZJD KHJFR OZL when encoded. Eventually, our teacher started getting wise to this code and figured out how to crack it. Therefore, we switched to a different code using numbers and letters, as shown here: A B C D E F G H I J K L... Using this code, my friend Jake s name would be encoded as This basic concept of using keys to scramble and descramble messages can be used to encode network communications as well. In today s security-conscious world, the need to encrypt the contents of network communications is preeminent. Using network monitoring tools (such as nmap discussed in the preceding chapter), it is relatively easy for a mischievous individual to sniff out network transmissions and read them. If they con-

3 Chapter 18: Using Encryption 711 tained sensitive information, such as usernames, passwords, financial data, credit card numbers, or personal information, we could have a real problem on our hands. To protect this information, we need to encrypt critical network communications. Unlike the simple codes I used in the fourth grade, network cryptography today uses much more sophisticated encoding mechanisms. There are two general approaches to doing this: Symmetric encryption Asymmetric encryption Let s first look at using symmetric encryption. Symmetric Encryption For my fourth-grade encryption system to work, my buddies and I all had to have exactly the same key to encrypt and decrypt our messages. Using the wrong key on either the sending or receiving end would result in gibberish. This system is called symmetric encryption. With symmetric encryption, the key used to encrypt a message is the same key used to decrypt the message. That means the sender and the receiver must both have the exact same key. This is shown in Figure NOTE Symmetric encryption is sometimes called secret key encryption. Symmetric encryption works very well. One of its key advantages is speed. It is much faster than asymmetric encryption (discussed later). However, one of the difficulties associated with symmetric encryption is how to securely distribute the key to all the parties that need to communicate with each other. For example, if you ve ever configured a WEP key on a wireless network, you know that you must create the key on the wireless access point, copy it to a USB thumb drive, sneaker-net it to each wireless client, and paste the WEP key in the configuration of the wireless NIC. Examples of cryptographic standards that use symmetric encryption include the following: Triple Data Encryption Standard (3DES) 3DES is commonly used by many Linux services. 3DES encrypts data in three stages. It uses either a 112-bit or a 168-bit key. Figure 18-1 Symmetric encryption

4 LPIC-1/CompTIA Linux+ Certification All-in-One Exam Guide 712 Advanced Encryption Standard (AES) AES is an improved version of 3DES. It supports 128-bit, 192-bit, and 256-bit keys. Blowfish Blowfish uses variable key lengths up to 448 bits. An important factor to keep in mind when selecting any encryption scheme is the number of bits used to encode the data. Older encryption schemes used only 40 or 56 bits to encode data. In today s computing world, this simply isn t strong enough. A fast PC from your local discount retail store can crack 40-bit encryption in a relatively short amount of time. When selecting an encryption scheme, you should pick one that supports a minimum of 128 bits. Basically, the longer the key, the more secure the data is. Because of the difficulties associated with key distribution, another encryption mechanism is commonly used today called asymmetric encryption. Let s look at how it works next. Asymmetric Encryption Unlike symmetric encryption, asymmetric encryption uses two keys instead of one: the public key and the private key. Data that has been encoded with the public key can be decoded only with the private key. Data that has been encoded with the private key can only be decoded with the public key. For this reason, asymmetric encryption is frequently referred to as public key cryptography. Rivest Shamir Adleman (RSA) and the Digital Signature Algorithm (DSA) are examples of cryptographic standards that use asymmetric encryption. NOTE Private/public key pairs should be much longer than those used for symmetric encryption. They should be 1024 bits or longer. This type of encryption is used to encrypt the contents of network communications as well as generate digital signatures. In a digital signature, the contents of a message aren t encrypted. Instead, the private key is used by the sender to create an encrypted hash of the message. This hash is sent along with the message to the recipient. The recipient generates its own hash of the message. Then it uses the public key to decrypt the hash sent with the message. If the hashes are the same, the recipient can be assured that the message arrived without being altered en route. Because of its flexibility, public key cryptography is widely used method for encrypting data. It allows you to easily scramble and send sensitive information over a public network, such as the Internet. If you ve ever bought anything online from an e- commerce web site, you ve used public key cryptography. When you send your credit card number, the retailer s web site should have encrypted your data and sent it using HTTPS so that prying eyes will be unable to read it. One of the key disadvantages of asymmetric encryption is speed. Symmetric encryption is much faster than asymmetric encryption. Hence, you will frequently see implementations that use a hybrid of both mechanisms. Asymmetric encryption is used for

5 Chapter 18: Using Encryption 713 an initial key exchange to securely copy a secret key to both parties in a session. Once that is done, both parties have the same key and can switch to symmetric encryption for the remainder of the session. Another problem associated with public key cryptography is the issue of how to verify that the public key is legitimate. To do that, we use a certificate authority (CA). The CA is a network service that is responsible for issuing and managing encryption keys. When a key pair is requested from a CA, it generates a public key and a private key simultaneously, using a specified encryption scheme, such as RSA or DSA. The private key in the pair is given only to the requesting entity. It is not shared with anyone else. The public key in the pair, on the other hand, can be made available to anyone who needs it. The primary role of the CA is to verify that parties involved in an encrypted exchange are who they say they are. A CA accomplishes this by issuing public key certificates. A public key certificate is a digital message signed with the private key that provides a cryptographic binding between the public key and the organization that owns the private key. A certificate contains the following information: The name of the organization The public key of the organization The expiration date of the certificate The certificate s serial number The name of the CA that signed the certificate A digital signature from the CA There are two types of CAs that you need to be familiar with: Internal CA An internal CA is one that is maintained by an organization for internal use. On most Linux distributions, the OpenSSL package is installed automatically and is used to create a CA on your system. This CA is used to create keys and issue certificates for services running on the server. However, this CA is not a trusted CA. If other systems connect to a service on your system via secure connection, users on a remote system will be issued a warning in their client software. This message will indicate that the certificate it received was valid but it didn t come from a trusted CA. That s because the certificate came from the CA on your own system. For internal communications, this doesn t represent a serious issue. We trust ourselves. If you re going to be dealing with external parties, however, an internal CA won t suffice. External CA External parties need assurance from a trusted, objective third party that the certificates they are receiving are legitimate and that you are who you say you are. This is done by using an external CA, such as VeriSign or GTECyberTrust. These organizations perform the same functions as an internal CA. However, they are globally trusted. For example, suppose you were to access a secure web site on the Internet using the Firefox web browser. If the site is using an external CA, you won t be presented with the warning that you see when using your internal CA. That s because your browser has been preconfigured with a list of trusted CAs, as shown in Figure 18-2.

6 LPIC-1/CompTIA Linux+ Certification All-in-One Exam Guide 714 Figure 18-2 Trusted CAs Let s look at an example to see how public key cryptography works. Suppose you re using a web browser to visit and you ve found some product that you just can t live without. You ve put it in your shopping cart and are in the process of checking out from the online store. The process shown in Figure 18-3 occurs as you submit your credit card information to the e-commerce web server. 1. Your browser requests the public key for from the external CA. 2. The CA returns the public key to the browser, which then uses that key to encrypt the message. 3. The browser sends the encrypted message to 4. The web server at the other end then uses its private key to decrypt the transmission. Figure 18-3 How public key encryption works

7 Chapter 18: Using Encryption 715 The whole reason this process works is because only the private key can decrypt a message encoded by the public key. For example, a hacker could easily intercept the public key used in the transaction in Figure But that s not a problem because it can t be used to decrypt information encrypted with the same public key (in this case, the credit card submission). That can only be done by the private key, which is kept safe on the web server and is never transmitted openly. Because your Linux system installed its own CA when you initially installed the system, you can use it to mint your own certificates and use them to encrypt both network transmissions and files in the file system. Let s review how this is done next. 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 and 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 now has 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 Let s begin by discussing how OpenSSH works. 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.

8 LPIC-1/CompTIA Linux+ Certification All-in-One Exam Guide 716 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 public keys 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 it 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.

9 Chapter 18: Using Encryption 717 Now that you understand how SSH connections are established, you need to learn how to configure OpenSSH. 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 installing 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 Option AllowUsers DenyUsers HostKey ListenAddress PermitRootLogin Port Protocol Description Table 18-1 Options in the sshd_config File Restricts logins to the SSH server to only the users listed. Specify a list of users separated by spaces. Prevents the users listed from logging in through the SSH server. Specify a list of users separated by spaces. Specifies which private host key file should be used by SSH. As discussed previously, the default private key file for SSH version 1 is /etc/ssh/ssh_ host_key for protocol version 1 while SSH version 2 can use the /etc/ssh/ ssh_host_rsa_key and /etc/ssh/ssh_host_dsa_key files. You can configure sshd to use multiple host key files. Be aware that if a key file has read or write permissions assigned to group or others, sshd will refuse to use it. If the host where sshd is running has multiple IP addresses assigned, you can restrict sshd to only listening on specific addresses using this parameter. The syntax is ListenAddress IP_address:port. Specifies whether you can authenticate through the SSH server as root. Specifies the port on which the sshd daemon will listen for SSH requests. Specifies which version of SSH to use. Specify one of the following: 1 Configures SSH version 1. 2 Configures SSH version 2. 2,1 Configures sshd to support both SSH versions, but preference is given to version 2.

10 LPIC-1/CompTIA Linux+ Certification All-in-One Exam Guide 718 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 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. Option Port Protocol StrictHostKeyChecking User Table 18-2 Options in the ssh_config File Description Specifies the port number to connect to on the SSH server system to initiate an SSH request. Specifies which version of SSH to use. Specify one of the following: 1 Configures SSH version 1. 2 Configures SSH version 2. 2,1 Configures the ssh client to support both SSH versions, but preference is given to version 2. The SSH server sends the SSH client its public key when you initiate an SSH connection. By default, the first time you connect to a given SSH server, you are prompted on the client end to accept the server s public key. However, you can change this behavior using the StrictHostKeyChecking parameter in the ssh_config file. If you set it to a value of yes, then the client can establish connections only to SSH servers whose public key has already been added to either the ~/.ssh/known_hosts or the /etc/ssh/ssh_known_hosts file. Be aware that if you do this and then want to connect to a new SSH server, you must manually add that server s key to one of the aforementioned files. Specifies the user to log in to the SSH server as.

11 Chapter 18: Using Encryption 719 Figure 18-4 Configuring the firewall to allow ssh traffic 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 on both the client and server systems, you ll still be able to authenticate. But if they aren t, then you won t be able to authenticate. For example, if I wanted to connect to a remote Linux system with a hostname of WS3 (which has an IP address of ) as the user rtracy using the ssh client on a local computer system, I would enter ssh l rtracy WS3 at the shell prompt. This is shown in Figure Notice in Figure 18-5 that I was prompted to accept the public key from WS3 because this was the first time I connected to this particular SSH server. Once done, I was authenticated to the remote system as the rtracy user (notice the change in the shell prompt). At this point, I have full access to the shell prompt on WS3 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, just enter exit at the shell prompt. TIP Windows workstations don t provide an ssh client. You can download the PuTTY.exe ssh client from the Internet and use it to connect to a Linux SSH server from a Windows workstation. Let s practice working with SSH in the following exercise. Figure 18-5 Connecting remotely via SSH

12 LPIC-1/CompTIA Linux+ Certification All-in-One Exam Guide 720 Exercise 18-1: Working with SSH VIDEO For more information watch Exercise In this exercise, you will set up the sshd daemon on your Linux system and then connect to it using the SSH client on another Linux system. Obviously, you ll need at least two Linux systems for this and the remaining exercises in this chapter. Complete the following: 1. Configure the SSH server system by doing the following: a. Boot the Linux system that you want to function as an SSH server and log in as a standard user. b. Open a terminal session. c. Switch to your root user account by entering su followed by your root user s password. d. At the shell prompt, use the package management utility of your choice to ensure the openssh package has been installed. e. At the shell prompt, enter vi /etc/ssh/sshd_config. f. Locate the PermitRootLogin setting. g. Press ins; then set PermitRootLogin to a value of no. h. Press esc; then enter :exit to save your changes and exit the editor. i. At the shell prompt, enter service sshd restart to restart the SSH service and apply the change. j. If necessary, open port 22 in the host firewall of the system where the SSH server is running. The steps for doing this will depend upon your particular distribution. 2. Create an SSH connection from a client system by doing the following: a. Start your second system that will function as an SSH client and log in as a standard user. b. Open a terminal session. c. Open an SSH session with the first Linux system by entering ssh l user_name IP_address_of_SSH_server at the shell prompt. For example, to connect to a system with an IP address of as the rtracy user on that system, I would enter ssh l rtracy at the shell prompt. d. If prompted, enter yes to accept the public key from the SSH server. e. Enter the password for the user you specified on the SSH server system. f. Enter exit at the shell prompt to log off from the remote system. 3. Practice working with SSH utilities from your client system by doing the following:

13 a. Run the ifconfig command on the remote system using SSH by entering ssh l user_name IP_address_of_SSH_server /sbin/ifconfig at the shell prompt. Chapter 18: Using Encryption 721 b. Enter the password of the remote user when prompted. You should see the networking configuration assigned to the various interfaces on the remote system. Notice that the connection automatically closed once the command finished running. c. Copy a file using a secure SSH connection by doing the following: i. Create a new file in your user s home directory by entering echo "This is my new file." > ~/mytestfile.txt at the shell prompt. ii. Copy this new file to the home directory for your remote user account on your SSH server system by entering scp ~/mytestfile.txt user_name@ IP_address_of_SSH_server: at the shell prompt. iii. Enter the remote user s password when prompted. You should see that the file was copied. iv. Use the ssh command to establish an SSH connection again with your SSH server system using the same username you entered previously to copy the file. v. Verify that the file exists in the remote user s home directory. vi. Enter exit to close the connection. d. Use the sftp command to copy the mytestfile.txt file down from the SSH server system to the local /tmp directory by doing the following: i. At the shell prompt of your workstation system, enter sftp user_ name@ IP_address_of_SSH_server. ii. Enter the remote user s password when prompted. iii. At the sftp> prompt, enter get mytestfile.txt /tmp/. iv. At the sftp> prompt, enter exit. v. At the shell prompt, enter ls /tmp. You should see the mytestfile.txt file that was copied down from the SSH server system. Now that you know how to use the SSH server and SSH client, you re ready to advance your knowledge by learning how to tunnel unencrypted traffic through an SSH connection. 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. A good example of this is the POP3 and IMAP daemons we discussed in the preceding chapter. We noted that for your Linux MTA to download messages to client systems, you must first enable either your POP3 or IMAP daemon via xinetd. Once done, end users can use an client to connect to the MTA and download their mail using the

14 LPIC-1/CompTIA Linux+ Certification All-in-One Exam Guide 722 appropriate protocol. The problem, however, is the fact that both of these daemons transfer data as clear text. That means the usernames and passwords users send to authenticate to the MTA are sent as clear text along with all of the contents of their 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 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 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 service sshd restart 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 Tells 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

15 Chapter 18: Using Encryption 723 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 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 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 An example of how to do this with the Evolution client is shown in Figure Note that I used the host name 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 host name. 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 client software. As far as it s concerned, it s retrieving 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. For example, telnet localhost 2345 When you do, you should see a connection established with the remote system where the POP3 daemon is running. An example is shown in Figure 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. Figure 18-6 Configuring Evolution to use an SSH tunnel

16 LPIC-1/CompTIA Linux+ Certification All-in-One Exam Guide 724 Figure 18-7 Testing an SSH tunnel with telnet 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; 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 of 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 /etc/ssh/ssh_config file on the X client system. Once done, you then need to set the X11Forwarding option to yes in the /etc/ssh/ sshd_config file on the X server system. Let s practice working with SSH tunneling in the following exercise. Exercise 18-2: Tunneling X Traffic with SSH VIDEO For more information watch Exercise In this exercise, you will set up the sshd daemon and ssh client to tunnel X traffic from the server to the client. Complete the following: 1. Configure the client system by doing the following: a. Log in to your client system as a standard user. b. Open a terminal session. c. At the shell prompt, enter xhost +X_server_IP_address. This tells the client to accept connections from the X server (where sshd is running). 2. Configure the server system by doing the following: a. Log in to your server system as a standard user.

17 b. Open a terminal session and switch to root using the su command. Chapter 18: Using Encryption 725 c. At the shell prompt, enter DISPLAY=X_client_IP_address:0.0; then enter export DISPLAY. This tells the X server to display its output on the remote X client. d. Edit the /etc/ssh/sshd_config file and set the X11Forwarding option to yes. Save your changes to the file and exit the editor. 3. Switch back to your client system. 4. At the shell prompt of the client system, enter ssh X l user_name IP_ address_of_ssh_server. 5. When prompted, enter the remote user s password. Notice that you are now logged in to the server system. 6. At the shell prompt, enter gedit to start the gedit text editor. Notice that even though you were logged in to the remote server system, the X application is displayed on the local desktop. An example is shown in Figure Because you used the X option, all of the X traffic is encrypted as it passes between systems. Before we finish discussing SSH, we need to look at configuring SSH to use public key authentication instead of usernames and passwords. Let s review how this is done next. Figure 18-8 Encrypting X traffic with SSH

18 LPIC-1/CompTIA Linux+ Certification All-in-One Exam Guide 726 Configuring SSH to Use Public Key Authentication In addition to authenticating to the SSH server with a username and password combination, you can also configure your sshd daemon to allow authentication using an RSA or DSA public key. For this to work, the public key of the user on the client system must be stored in the ~/.ssh/authorized_keys file in the home directory of the user on the server system that you will authenticate as. To do this, you need to securely copy the public key from the client system to the server system. The private key, of course, remains on the client system. If you configure the SSH server to use public key authentication, the SSH client tells the SSH server which public key should be used for authentication when the SSH session is initially established. The SSH server then checks to see if it has that client s public key; if it does, it will generate a random number and encrypt it with that public key. It then sends the encrypted number to the client, which decrypts it using the private key associated with the public key. The client then calculates an MD5 checksum of the number it received from the server. It sends the checksum back over the SSH server system, which then calculates its own MD5 checksum of the number it originally sent. If the two checksums match, then the user is automatically logged in. To configure public key authentication, the first thing you need to do is create the public/private key pair on the client system so that you can send the public key to the SSH server. This can be done using the ssh-keygen command. Complete the following: 1. At the shell prompt of the client system, enter ssh-keygen t rsa or sshkeygen t dsa, depending upon which encryption method your SSH server supports. To be safe, you can simply use both commands to make two key pairs, one for RSA encryption and the other for DSA encryption. 2. When prompted for the file in which the private key will be saved, press enter to use the default filename of ~/.ssh/id_rsa or ~/.ssh/id_dsa. The associated public key will be saved as ~/.ssh/id_rsa.pub or ~/.ssh/id_dsa.pub, respectively. 3. When prompted, enter a passphrase for the key. It is important that you use a passphrase. If you don t, then anyone who manages to get a copy of your key files could authenticate to the SSH server without being required to enter a passphrase. Assigning a passphrase to the key renders the key useless if you don t know it. At this point, your key pair is created. An example of creating an RSA key pair is shown here: rtracy@ws1:~> ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/rtracy/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/rtracy/.ssh/id_rsa. Your public key has been saved in /home/rtracy/.ssh/id_rsa.pub. The key fingerprint is: ba:14:48:14:de:fd:42:40:f2:4b:c8:8b:03:a4:6d:fc rtracy@ws1

19 Chapter 18: Using Encryption 727 The key s randomart image is: +--[ RSA 2048] oo oo + = o o + = + o o + + o. o E o S.. o. o rtracy@ws1:~> The next thing you need to do is to copy the public key you just created to the SSH server. An easy (and secure) way to do this is to use the scp command you learned about earlier in this chapter. The syntax is scp ~/.ssh/key_name.pub user_name@address_of_ssh_server:filename In the example shown here, the RSA public key for the local rtracy user on WS1 is copied to the home directory of the rtracy user on WS3 and saved in a file named keyfile. rtracy@ws1:~> scp ~/.ssh/id_rsa.pub ws3:keyfile Password: id_rsa.pub 100% KB/s 00:00 rtracy@ws1:~> At this point, the contents of the key file you just copied need to be appended to the end of the ~/.ssh/authorized_keys file in the home directory of the user you will connect to the SSH server as. An easy way to do this is to connect to the SSH server system using a standard (password-authenticated) SSH session and then use the cat command to append the contents of the key file to the end of the ~/.ssh/authorized_keys file in the user s home directory. An example of how to do this is shown here: rtracy@ws1:~> ssh -l rtracy ws3 Password: Last login: Thu Jun 2 15:05: from rtracy@ws3:~> mkdir ~/.ssh rtracy@ws3:~> cat keyfile >> ~/.ssh/authorized_keys rtracy@ws3:~> In this example, I logged in to the WS3 system via an SSH connection as the remote rtracy user and then created the hidden.ssh directory in that user s home directory. I had to create the directory because it didn t exist yet. If the.ssh directory already exists, you can skip this step and just append the contents of the key file to the end of the authorized_keys file. Notice in the example that I used the cat command with the >> redirection characters to add the contents of the file named keyfile to the end of the authorized_keys file. In this example, the authorized_keys file didn t exist yet, so the redirection process automatically created it for me. Because of this, I could have actually just used a single > redirection character because the file didn t exist.

20 LPIC-1/CompTIA Linux+ Certification All-in-One Exam Guide 728 If, on the other hand, the authorized _keys file does already exist, it s very important that you remember to use the >> redirection characters instead of >. Remember, using >> will append the output of the command to the end of the specified file. Using a single redirection > character will overwrite the entire file with the output of the command. That wouldn t be a good thing if the authorized_keys file already had several keys in it that you wanted to keep. You can now test the configuration to see if public key authentication works. If you re still logged in to an SSH session with the SSH server, exit out of it. Then establish a new SSH session with the server. You should be prompted for the key file s passphrase instead of a username and password, as shown in Figure Once you enter the passphrase, you will be authenticated to the SSH server. Notice in the next example that no password was requested to establish the SSH session: rtracy@ws1:~> ssh -l rtracy ws3 Last login: Thu Jun 2 16:13: from rtracy@ws3:~> If desired, you can use the ssh-agent command to eliminate the need to enter the passphrase every time you establish an SSH connection. Complete the following: 1. At the shell prompt of your client system, enter ssh-agent bash. 2. At the shell prompt, enter ssh-add ~/.ssh/id_rsa or ssh-add ~/.ssh/id_dsa, depending upon which key file you have created. 3. When prompted, enter the key file s passphrase. When you do, you should be prompted that the identity has been added. An example follows: rtracy@ws1:~> ssh-agent bash rtracy@ws1:~> ssh-add ~/.ssh/id_rsa Enter passphrase for /home/rtracy/.ssh/id_rsa: Identity added: /home/rtracy/.ssh/id_rsa (/home/rtracy/.ssh/id_rsa) rtracy@ws1:~> Once done, the ssh-agent process stores the passphrase in memory. It then listens for SSH requests and automatically provides the key passphrase for you when requested. Let s practice configuring SSH to use public key authentication in the following exercise: Figure 18-9 Supplying the key file s passphrase

21 Exercise 18-3: Configuring Public Key Authentication Chapter 18: Using Encryption 729 VIDEO For more information watch Exercise In this exercise, you will generate an RSA key pair on your client system and copy the public key to the SSH server to enable public key authentication. Complete the following: 1. Generate an RSA key pair on your client system by doing the following: a. Log in to your client system as a standard user. b. Open a terminal session. c. At the shell prompt, enter ssh-keygen t rsa. d. When prompted for the file in which the private key will be saved, press enter to use the default filename of ~/.ssh/id_rsa. e. When prompted, enter a passphrase for the key. 2. Configure the server system to use public key authentication by doing the following: a. Copy the public key you just created to your SSH server system by entering scp ~/.ssh/id_rsa.pub user_name@address_of_ssh_server:mykeyfile. b. Enter the remote user s password when prompted. c. Establish an SSH session with the remote system as the user you intend to authenticate as using public key authentication. Use the following command: ssh l user_name address_of_ssh_server. d. Enter the remote user s password when prompted. e. At the shell prompt of the remote system, check to see if the.ssh hidden directory already exists by entering ls la at the shell prompt. If the.ssh directory doesn t exist, create it using the mkdir ~/.ssh command. Otherwise, go on to the next step. f. At the shell prompt of the remote system, enter cat mykeyfile >\> ~/.ssh/ authorized_keys. g. Enter exit at the shell prompt to close the SSH session. 3. Test the new configuration by doing the following: a. At the shell prompt of your client system, enter ssh l user_name address_ of_ssh_server. b. When prompted, enter the passphrase you assigned to your RSA private key. At this point, you should be automatically authenticated to the SSH server. c. Close the session by entering exit at the shell prompt.

22 LPIC-1/CompTIA Linux+ Certification All-in-One Exam Guide Configure ssh-agent to remember your private key passphrase by doing the following: a. At the shell prompt of your client system, enter ssh-agent bash. b. At the shell prompt, enter ssh-add ~/.ssh/id_rsa. c. When prompted, enter the key file s passphrase. When you do, you should be prompted that the identity has been added. d. At the shell prompt of your client system, enter ssh l user_name address_ of_ssh_server. You should be automatically authenticated to the SSH server without being prompted for the private key passphrase. Great work! You re an SSH pro now! Before we end this chapter, there s one more encryption-related topic we need to address: encrypting files. Let s do that next. 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. There are a wide variety of tools you can use 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 Let s begin by discussing how GPG works. 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 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 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 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. GPG first generates a random symmetric key and uses it to encrypt the message to be transferred. The symmetric key itself is then encrypted using

23 Chapter 18: Using Encryption 731 the recipient s public key and sent along with the message that was encrypted using the symmetric key. 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@ws3:~> gpg --gen-key gpg (GnuPG) 1.4.2; Copyright (C) 2005 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. gpg: directory `/home/rtracy/.gnupg created gpg: new configuration file `/home/rtracy/.gnupg/gpg.conf' created gpg: WARNING: options in `/home/rtracy/.gnupg/gpg.conf are not yet active during this run gpg: keyring `/home/rtracy/.gnupg/secring.gpg' created gpg: keyring `/home/rtracy/.gnupg/pubring.gpg' created Please select what kind of key you want: (1) DSA and Elgamal (default) (2) DSA (sign only) (5) RSA (sign only) Your selection?

24 LPIC-1/CompTIA Linux+ Certification All-in-One Exam Guide Select the type of key you want to create. Usually you will use the default option (1), which uses DSA and Elgamal. You are prompted to specify the size of the key, as shown here: DSA keypair will have 1024 bits. ELG-E 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 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 specified number of days, weeks, months, or years. 5. Next, 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, as it will be used later during the encryption process. In the next example, I entered rtracy for my real name: You need a user ID to identify your key; the software constructs the user ID from the Real Name, Comment and Address in this form: "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>" Real name: rtracy 6. When prompted, enter your 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 (Hello World) <rtracy@ws3>" 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 here: You need a Passphrase to protect your secret key. Enter passphrase: 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 >

25 Chapter 18: Using Encryption > < > < 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. You can now use this 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@ws3:~> 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-10, the differences between the original file and the encrypted file are shown. Figure Viewing a file encrypted with gpg

26 LPIC-1/CompTIA Linux+ Certification All-in-One Exam Guide 734 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@ws3:~> gpg --output mytestfile.txt.decrypted --decrypt mytestfile.txt.gpg You need a passphrase to unlock the secret key for user: "rtracy (Hello World) <rtracy@ws3>" 2048-bit ELG-E key, ID 28D32B0D, created (main key ID 01F5E039) gpg: gpg-agent is not available in this session gpg: encrypted with 2048-bit ELG-E key, ID 28D32B0D, created "rtracy (Hello World) <rtracy@ws3>" rtracy@ws3:~> cat mytestfile.txt.decrypted This is my new file. rtracy@ws3:~> If you want to send the encrypted file to others, you can export your public key and send it to them. To do this, you enter gpg --export key_user_name > 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 gpg --export rtracy > gpg.pub. This is shown in the example here: rtracy@ws3:~> gpg --export rtracy > gpg.pub You can then send this key file to the user whom you want to be able to open your encrypted files. That user can import your public key into her GPG keyring using the gpg --import public_key_filename command at the shell prompt. In the example shown here, I used scp to copy the public key file from the WS3 system to the WS1 system. I then used gpg to import the public key. rtracy@ws1:~> gpg --import gpg.pub gpg: directory `/home/rtracy/.gnupg' created gpg: new configuration file `/home/rtracy/.gnupg/gpg.conf' created gpg: WARNING: options in `/home/rtracy/.gnupg/gpg.conf are not yet active during this run gpg: keyring `/home/rtracy/.gnupg/secring.gpg' created gpg: keyring `/home/rtracy/.gnupg/pubring.gpg' created gpg: /home/rtracy/.gnupg/trustdb.gpg: trustdb created gpg: key 01F5E039: public key "rtracy (Hello World) <rtracy@ws3>" imported gpg: Total number processed: 1 gpg: imported: 1 rtracy@ws1:~>

27 Chapter 18: Using Encryption 735 You can view the files in your gpg keyring using the gpg --list-keys command, shown in the example here: gpg --list-keys /home/rtracy/.gnupg/pubring.gpg pub 1024D/01F5E uid rtracy (Hello World) sub 2048g/28D32B0D In this example, you can see that the public key I created earlier on WS3 is now imported into the rtracy user s gpg keyring on WS1. 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. With the public key imported, I can now decrypt files sent to me from the rtracy user on the WS3 system. The syntax for doing this is gpg --output output_filename --symmetric encrypted_filename. For example, if I ed (or scp ed) the mytestfile.txt.gpg-encrypted document from my WS3 system to my WS1 system, I would enter the following command: 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. This is shown in Figure Once this is done, the decrypted version of the file is created and is accessible to the local user. Let s practice working with GPG in the following exercise. Figure Decrypting a gpgencrypted file