This chapter covers the benefits of the SSH™ protocol, the sequence of
events that occur when a secure connection is made to a remote system, the
different layers of SSH, and methods to ensure SSH is used by users
connecting to your system.
Common methods for remotely logging into another system through a shell
(telnet, rlogin, or
rsh) or copying files between hosts
(ftp or rcp) do not encrypt data
that is sent over the connection between the client and the server, and should
be avoided. Instead, you should only connect to a remote host using a
secure shell or an encrypted virtual private network. Using secure methods
to remotely log in to other systems will decrease the security risks for
both your system and the remote system.
SSH (or Secure SHell) is a
protocol for creating a secure connection between two systems. In the
SSH protocol, the client machine initiates a connection with a server
machine. The following safeguards are provided by SSH:
After an initial connection, the client can verify that it is
connecting to the same server during subsequent sessions.
The client can transmit its authentication information to the
server, such as a username and password, in an encrypted format.
All data sent and received during the connection is transferred using
strong encryption, making it extremely difficult to decrypt and read.
The client has the ability to use X11[1] applications launched from the
shell prompt. This technique provides a secure, graphical interface
(called X11 forwarding).
The server benefits from SSH, as well, especially if it is running a
number of services. If you use port forwarding,
otherwise insecure protocols (for example, POP) can be encrypted for
secure communication with remote machines. SSH makes it relatively simple to encrypt
different types of communication normally sent insecurely over public
networks.
Red Hat Linux 7.2 includes the OpenSSH server
(openssh-server) and client
(openssh-clients) packages, as well as the general
OpenSSH package (openssh) which must be installed
for either of them to work. Please see the
Official Red Hat Linux Customization Guide for instructions on installing and
deploying OpenSSH on your Red Hat Linux system.
The OpenSSH packages require the OpenSSL package
(openssl). OpenSSL installs several important
cryptographic libraries that help OpenSSH provide encrypted
communications. You must install the openssl
package before installing any OpenSSH packages.
A large number of client and server programs can use the SSH
protocol, including many open source and freely available
applications. Several different SSH client versions are available for
almost every major operating system in use today. Even if the users
connecting to your system are not running Red Hat Linux, they can still find and
use an SSH client native for their operating system.
Threats to network traffic include packet sniffing, DNS and IP
spoofing[2] and the promulgation of fake routing information. In general
terms, these threats can be categorized as follows:
Interception of communication between two
systems — In this scenario, a third party exists
somewhere on the network between communicating entities and
makes a copy of the information being passed between them. The
intercepting party may intercept and keep the information, or it
may alter the information and send it on to the intended recipient.
Impersonation of a particular host —
Using this strategy, an intercepting system pretends to be the
intended recipient of a message. If the strategy works, the
client remains unaware of the deception and continues to
communicate with the interceptor as if its traffic had
successfully reached its destination.
Both techniques cause information to be intercepted, possibly for
hostile reasons. The results can be disastrous, whether
that goal is achieved by listening for all packets on a LAN or a
hacked DNS server pointing to a maliciously duplicated host.
If SSH is used for remote shell logins and file copying, these security
threats can be greatly diminished. A server's digital signature
provides verification for its identity. The entire communication
between client and server systems cannot be used if intercepted,
because each of the packets is encrypted. Attempts to spoof the
identity of either side of a communication will not work, since each
packet is encrypted using a key known only by the local and remote
systems.
