Certification Objective 11.05: The Secure Shell Package

---

Red Hat Enterprise Linux 3 installs the Secure Shell (SSH) packages by default, using the openssh-server, openssh-clients, and openssh RPMs. The Secure Shell and Secure Copy programs, ssh and scp, are replacements for the rsh, telnet, and rcp programs. They encrypt communication between different computers. The secure daemon, sshd, listens for all inbound traffic on port 22. The SSH configuration files are located in the /etc/ssh directory.

The Secure Shell daemon works because it encrypts messages. RHEL 3 incorporates SSH version 2, which includes an enhanced key exchange algorithm.

Basic Encrypted Communication

Basic encryption in computer networking normally requires a private key and a public key. You keep the private key and send the public key to others. When they want to send data to you through SSH, their messages are encrypted with the public key. Your computer can descramble the message with the private key.

Encryption keys are based on random numbers. The numbers are so large (typically 512 bits or more), the chance that someone will break into your system, at least with a PC, is quite small in the foreseeable future. Private and public encryption keys are based on a matched set of these random numbers.

Private Keys

Your private key (essentially a file with your special number) must be secure. When you enable an application, it can attach the key to your messages. Anything you send-say, from your e-mail account-can then be digitally signed and encrypted. The public key is added to the end as part of your signature. Only the recipient will be able to decrypt the message.

Public Keys

Your public key value is just that, publicly available. A central authority such as Verisign, Globalsign, or Thawte provides public access to public keys they have created. If they generate a private key for you, they'll keep a secure copy on their system. You can just attach your public key to the e-mail, or the end users can publicly retrieve it from the Web site associated with the central authority.

The example shown in Figure 11-10 lists the directories and files associated with SSH usage as well as a public key that has been added to your 'keyring.'

Figure 11-10: A public key

This key is like a password used to encrypt your data. Imagine trying to remember the 1024-bit number expressed in hexadecimal value as shown below. That is why the applications save this value for you, on a 'public keyring.' You can add as many public keys from other users, sites, and services as you wish.

3081 8902 8181 00D4 596E 01DE A012 3CAD 51B7 7835 05A4 DEFC C70B 4382 A733 5D62 A51B B9D6 29EA 860B EC2B 7AB8 2E96 3A4C 71A2 D087 11D0 E149 4DD5 1E20 8382 FA58 C7DA D9B0 3865 FF6E 88C7 B672 51F5 5094 3B35 D8AA BC68 BBEB BFE3 9063 AE75 8B57 09F9 DCF8 FFA4 E32C A17F 82E9 7A4C 0E10 E62D 8A97 0845 007B 169A 0676 E7CF 5713 1423 96E0 8E6C 9502 0301 0001

Your private key is similar, but you must keep it private, or this whole system fails. Keeping it private means no one should have access to your PC. If your PC is public, secure your system with a passphrase (password), as shown in Figure 11-11, in order to use this key.

Figure 11-11: Generating encryption keys

How to Generate Your Keys

There are a few SSH-oriented utilities you need to know about:

• sshd The daemon service; this must be running for inbound Secure Shell client requests.

• ssh-agent A program to hold private keys used for RSA authentication. The idea is that the ssh-agent command is started in the beginning of an X session or a login session, and all other windows or programs are started as clients to the ssh-agent program.

• ssh-add Adds RSA identities to the authentication agent, ssh-agent.

• ssh The Secure Shell command, ssh, is a secure way to log in to a remote machine, similar to Telnet or rlogin. To make this work, you need a private key on the server and a public key on the client. Take the public key file, identity.pub or id_dsa.pub, created later in this section. Copy it to the client. Place it in the home directory of an authorized user, in the ~/.ssh/authorized_keys or ~/.ssh/authorized_keys2 file.

• ssh-keygen A utility that will create your keys for you. The ssh-keygen -t keytype command will create the keys you desire. The keytype can be dsa (Digital Secure Algorithm) or rsa1 (RSA Security). The commands work as shown in Figure 11-11.

All you need to do is transfer the public key, with the .pub extension, to an authorized user. It's important to add a passphrase to protect that digital signature. In the worst case, a cracker could use this file to effectively steal your identity.

Why Use SSH?

The Internet is a public network. If you're connected to the Internet, anyone in the world could conceivably access your computer through this public network. All that is needed is Internet access from an anonymous location. In other words, a skilled cracker may be able to capture your passwords from a computer in a public library.

In contrast, private networks are used for security applications. Merchants who dial into a central server to check authorized credit card numbers are connecting to a private network. Access to such private networks can be expensive.

Unix and the network that became the Internet started in an educational setting, where there is a premium on the free exchange of information. While the resulting openness of the Internet is good, it can present security challenges. The original Unix tools developed for networks were not designed with security in mind.

These tools include telnet, ftp, and the 'r' (remote) commands (rlogin, rcp, rsh). These utilities pass all information, including login names and passwords, across the network in clear text format. Anyone with a simple protocol analyzer such as Ethereal can find your password in this way. The Ethereal output shown in Figure 11-12 highlights one of the letters in a Telnet password on my private LAN (it's an 'e'). The other Telnet packets contain the other letters and/or numbers of the password.

Figure 11-12: It's easy to decipher a clear text password.

This is the Kerberos version of the Telnet server discussed in Chapter 7. While it's more secure than the older Telnet server, you can still find the clear text password using a tool such as Ethereal.

On The Job 

We do not in any way endorse the cracking of passwords. However, as a system administrator, you do need to know your vulnerabilities. If you can trace clear text passwords on your own network, you are at risk.

The Secure Shell utilities were an answer to this problem, using high encryption standards. The Secure Shell tools replaced their insecure brethren and provided full encryption of all data between the hosts that is very hard to break, even by the 'brute force' method.

Brute Force Decryption

All computer data, including passwords, can be broken down into bits and bytes-in other words, 1s and 0s. If you can see the pattern of bits and bytes, you can decipher the password.

By convention, every character is associated with 7 of the 8 bits in a byte. Now assume you have 8 characters in a password. This makes for a 56-bit password. All you need to do to find the password is to compare it with every possible combination of bits and bytes. In other words, one of the bit-based values between 0 and 256 (72,057,594,037,927,936) represents your password.

While this may seem like a large number, it is in fact trivial for a higher-end PC, which could decipher such a password in a matter of hours. This suggests that the older standard for secure HTTP Web pages, 40-bit encryption, is not very secure. On the other hand, the higher-level 128-bit-encrypted browsers are a lot more secure. It would take more than a few years for the latest PCs to break through such encryption.

By default, the ssh-keygen command creates encryption keys with 1024 bits. Breaking into such systems is beyond the capabilities of the latest PCs using brute force methods.

Lost Passphrase on Private Keys

Unfortunately, if you lose the passphrase on your private encryption key, there is no way to recover. You would need to start over, which means you would need to create a new set of keys and send your new public key to all concerned for them to replace your old public key.

PGP (Pretty Good Privacy)

E-mail has become a standard fixture in everyday business; e-mail security is a significant issue. One of the current standards for managing e-mail security is known as PGP (Pretty Good Privacy), developed by Phil Zimmerman. Like SSH, PGP provides a private- and public-key system for e-mail clients. The public key is usually attached to the end of the data, as shown in the next example.

The Linux implementation of PGP is known as GPG, the Gnu Privacy Guard. GPG is an implementation of the OpenPGP standard. Both standards are now common ways people and companies protect their correspondence.

********************************************************************* To:   Dreg (SD444466) From: The SANS NewsBites service ************************* ---BEGIN PGP SIGNED MESSAGE--- Hash: SHA1 ... (text removed) Please feel free to share this with interested parties via e-mail (not on bulletin boards).  For a free subscription, (and for free posters) e-mail [e-mail] with the subject: Subscribe NewsBites ... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (BSD/OS) Comment: For info see http://www.gnupg.org iD8DBQE63beV+LUG5KFpTkYRAu/WAJ0fUwoQFUOETTd+wAbe1L784S3PDwCfULr0 DXDk20qZotKDLMfjLz1Gty4= =K1Av -----END PGP SIGNATURE-----

Notice in the previous listing that the BSD/OS (Berkeley Software Distribution/Operating System) is also using GPG, which is also known as GnuPG.

Validating RPMs with GPG

If you download an RPM from the Internet and would like to verify that it is an official unadulterated Red Hat RPM, GPG can help. All you need is the Red Hat Enterprise Linux public key. It's available from at least three different locations:

• Each Red Hat Enterprise Linux installation CD, in the main directory, in the RPM-GPG-KEY file

• On a standard Red Hat Enterprise Linux 3 installation, in /usr/share/rhn/RPM-GPG-KEY

• Online from www.redhat.com

First, you need to import the key. For example, if you want to import the key from the Red Hat installation CD, mounted on /mnt/cdrom, run the following command:

# rpm --import /mnt/cdrom/RPM-GPG-KEY

Now you should find the RPM-enabled key in the /var/lib/rpm/Pubkeys file. Next, you can verify the package's PGP-encrypted checksum using the rpm -vK packagename command. For example, if you wanted to verify the openoffice RPMs on a downloaded installation CD, run the following command:

# rpm -vK /mnt/cdrom/RedHat/RPMS/setup-*

On The Job 

Older versions of Red Hat Linux (and RHEL 2.1) used the gpg --import keyfile command to download the Red Hat public GPG key. This is no longer possible with the advent of RPM version 4.1.

---