Overview of SSH

Secure Shell (SSH) is a program used to secure communication between two
entities. SSH uses a client/server architecture, where SSH clients, available on
all versions of Windows, different flavors of Unix, and various Macintosh
operating systems, connect to SSH servers, which can be operating systems
such as Sun Solaris or Microsoft Windows or devices such as a Cisco router. In
its simplest sense, SSH is used to execute remote commands securely on
another entity, often used as a replacement for Telnet and the Berkeley “R”
protocols such as remote shell (RSH) and remote login (Rlogin), discussed further
in Chapter 8. In addition to executing remote commands, SSH is used as a
secure remote copy utility, replacing traditional protocols such as the File
Transfer Protocol (FTP) and Remote Copy Protocol (RCP).
Despite the name Secure Shell, SSH is not a shell at all. Unlike other traditional
shells found in different flavors of Unix, such as BASH, KORN, and C,
SSH provides encryption between entities, not a shell interface between entities.
The encryption methods and algorithms used for SSH are all based on
industry standards such as 3DES, Blowfish, Twofish, and AES.
The paragraphs that follow discuss the basics of SSH: how it works, what
it can be used for, and why it is tremendously flexible. This chapter is useful
for readers who do not have experience with SSH or who have never been
introduced to it aside from a casual reference. Advanced users may want to
skip to the next chapter. Specifically, this chapter discusses the following topics:
■■ Differences between SSH1 and SSH2
■■ Uses of SSH
■■ Client/server architecture for SSH
■■ SSH’s Encryption Architecture
■■ Basic miscues with SSH
■■ Types of SSH clients/servers
■■ Basic setup of SSH
■■ Summary of SSH’s optimal uses
Differences between SSH1 and SSH2
SSH version 1 (SSH1) was the first iteration of SSH; however, SSH1 had several
limitations, including the use of port forwarding, which led to the second iteration
of SSH: SSH version 2 (SSH2). In addition to its limitations, SSH1 had
several security issues associated with its cryptography, which also led to the
establishment of SSH2.
The differences between SSH1 and SSH2 may seem minor to most endusers;
however, the differences are quite significant. SSH1 and SSH2 are two
different protocols. SSH2 was completely rewritten from scratch, giving it
more security, performance, and flexibility than SSH1. Also, SSH1 and SSH2
encrypt communication differently, which mitigated several of the documented
issues with SSH1’s encryption methods. SSH1 is not being developed
now, whereas SSH2 is becoming the standard when referring to SSH. There are
still many implementations of SSH1, but the implementations are becoming
fewer and more in favor of SSH2. For the purposes of this book, I do not refer
to, use, or demonstrate the use of SSH1. I concentrate solely on the usage and
optimization of SSH2. The following is a short list of the advantages of using
SSH2 instead of SSH1:
■■ Significant improvements with security and speed
■■ Considerably greater flexibility with Secure File Transfer Protocol
(SFTP)
■■ Interoperability with several different public key algorithms, including
Diffie-Hellman (see http://www.rsasecurity.com/rsalabs/faq/3-6-1.
html for more information on Diffie-Hellman)
■■ New architecture that requires far less code usage
Various Uses of SSH
SSH can be used in a variety of ways, depending on your network environment
and business requirements. The flexibility that SSH provides in any type
of dynamic or static environment gives it a significant advantage over other
utilities in the industry, both security-focused utilities, such as IPSEC, and
nonsecurity-focused utilities, such as FTP. SSH can be used for multiple users
with just a single process (daemon) or service running on the server, with most
of the configuration required on the client side. During the course of this book,
I explore the various uses of SSH; however, I take the better half of this chapter
to describe the different uses of SSH to illustrate its full capabilities:
■■ Security
■■ Remote command execution
■■ Remote file transfer
■■ Remote network access
■■ Secure management
■■ Proxy services
Security
The implementation of SSH in a trusted or nontrusted environment can protect
against many of the security issues with Internet Protocol version 4 (IPv4).
IPv4 has been plagued with security issues ranging from poor initial sequence
numbers (ISN) in TCP header packets, which leads to session hijacking, to
unauthenticated address resolution packets (ARPs) being distributed to the
network. The use of SSH not only protects against the common LAN attacks
described previously; it guards against the following types of attacks as well:
Spoofing of IP addresses. A remote device, usually an operating system,
can change its IP address and pretend to be a different source, usually a
trusted source.
Data modification. As data is passed through corporate networks and
the Internet, any intermediary can modify the data while it is in transit.
ARP pollution. This occurs when incorrect ARP packets to redirect and
capture sensitive data are distributed.
Session hijacking. This occurs when individuals guess or predict the
ISN in TCP headers, gaining control of Telnet and RSH sessions.
Clear-text data. This occurs when critical or sensitive clear-text data, such
as usernames, passwords, and commands, is intercepted.
The preceding list is not exhaustive, as SSH can protect against many other
attacks, which may be direct or indirect. Another reason SSH is so popular is
its ability to protect against network sniffing on both Local Area Networks
(LANs) and Wide Area Networks (WANs). That feature allows network
administrators and server administrators to manage and connect to remote
systems without the risk of losing sensitive information to unauthorized users.
Figure 1.1 shows a Telnet packet between two entities in clear-text:
Notice in Figure 1.1 that the username is in the clear-text, “kusum,” and the
password is also in the clear-text, “password.” The session can be captured by
any type of network sniffer, as long as the session is in clear-text. Some of the
most common and vulnerable connections that often get targeted for sensitive
information such as passwords are Telnet, FTP, POP3, SMTP, IMAP, SNMP,
and HTTP. Figure 1.2 shows an SSH packet between the same two entities used
in Figure 1.1.
Notice in Figure 1.2 that none of the information is in clear-text or comprehendible,
thus being encrypted. This connection mirrors the Telnet connection
(remote command line execution), but with significantly greater security over
the password and the username “kusum.”
SSH provides the following three key security features:
Encryption. SSH encrypts all communication with a variety of cipher
algorithms to choose from.
Two-factor authentication. SSH can require a username/password or
public key for authentication. In addition, these two options can be used
together for two-factor authentication
Integrity. SSH can create a digital signature of the data transferred from
one entity to another, ensuring that the data has not been modified or
tampered with in any way.
Remote Command Line Execution
SSH offers the ability to execute commands on a remote entity, which can be an
operating system or a network device. In the Unix world, SSH gives the
remote user the shell listed in the passwd file of the /etc directory; however,
the communication is still encrypted over the wire. For example, based on the
following Unix passwd file:
root:x:0:0:root:/root:/bin/bash
kusum:x:4:101:kusum:/home/kusum:/bin/bash
shreya:x:4:102:shreya:/home/shreya:/bin/bash
sudhanshu:x:4:103:sudhanshu:/home/sudhanshu:/bin/csh
sangeeta:x:4:104:sangeeta:/home/sangeeta:/bin/ksh
jignesh:x:4:105:jignesh:/home/jignesh:/bin/csh
kanchan:x:4:106:kanchan:/home/kanchan:/bin/bash
katie:x:4:107:katie:/home/katie:/bin/csh
amit:x:4:108:amit:/home/amit:/bin/bash
rohan:x:4:109:rohan:/home/rohan:/bin/sh
anand:x:4:110:anand:/home/anand:/bin/bash
amiee:x:4:111:amiee:/home/amiee:/bin/sh
neeraja:x:4:112:neeraja:/home/neeraja:/bin/sh
jum4nj1:x:4:113:jum4nj1:/home/jum4nj1:/sbin/nologin
root gets a bash shell, sudhanshu gets a C shell, neeraja gets a Korn shell, and
the user jum4nj1 is not allowed to log in, since the shell allocated to jum4nj1’s
account is nologin, despite making a valid SSH connection. The SSH daemon
running on the Unix server would query the information from the passwd file
in order to process usernames for authentication. SSH does not use its own
username and passwords for authentication; it uses the operating system’s
username and password information, which makes the process a lot easier to
use. The result would be that valid accounts with an appropriate shell in the
passwd file would be authenticated and given the correct shell, while being
encrypted with SSH.
The process works a bit differently in the Windows world, but the result is
still the same. Since Windows does not have different shell options, all SSH
users would be given a command prompt (cmd.exe) or some form of the command
prompt itself. Similar to the Unix world, SSH services in Windows use
the existing password database (the SAM or ntds.dit files) for authentication.
Remote File Transfer
Remote file transfer is similar to remote command line execution. SSH offers
the ability to retrieve and send files to and from a remote entity. Remote file
transfer actually comes in two forms in the Unix world. SSH offers Secure
Copy Protocol (SCP) in some installations of SSH1 and SSH2, or Secure File
Transfer Protocol (SFTP), in most installations of SSH2. In the Windows world,
only SFTP exists. Both SCP and SFTP provide similar, if not the same, function,
which is to put and get files from a remote entity in a secure fashion. SFTP uses
the existing SSH daemon on Unix and the existing SSH service on Windows.
There is no extra step required to enable secure file transfer; it is automatically
enabled on most versions of SSH2. Many SSH clients also come packaged with
SCP or SFTP clients; therefore, the use and execution of the additional functionality
is very straightforward. Furthermore, there are SCP/SFTP clients
only, such as PuTTY, which are discussed in Chapter 3. But several installations
of SSH clients have some type of file transfer utility included.
Similar to the Telnet session described previously, most SCP or SFTP installations
are able to protect against the weaknesses of their counterpart: cleartext
communication of FTP. Figure 1.3 shows an FTP packet between two
entities in clear text.
Notice in Figure 1.3 that the FTP username (kusum) and password (dwivedi)
is in clear-text, similar to the Telnet session described previously. Furthermore,
since FTP provides remote file service, SCP and SFTP provide the same service
with a significant amount of security. Also, with a single service, remote command
line execution and secure file transfer can be provided, instead of
enabling two different services such as Telnet and FTP. Figure 1.4 shows the
same two entities but uses SFTP instead.
Notice in Figure 1.4 that none of the information is in clear-text and readable
to anyone; thus, it is encrypted. In addition, Figure 1.5 shows the SFTP client
interface, which is similar to many FTP interfaces.
While SCP and SFTP are good replacements for FTP, in certain environments
they also can replace other risky protocols such as Windows’ Server
Message Block (SMB) and Unix’s Network File Server (NFS). Both SMB and
NFS networking have had problems with security and continue to plague
many networks today. The use of SFTP for a common file server can reduce or
even eliminate reliance on SMB or NFS networking. Also, using a standard
protocol such as SFTP, both Unix and Windows clients can access the same
server, since both can communicate and use SSH but cannot necessarily communicate
with SMB or NFS. Note that SSH can make the file-transfer process
longer than FTP, NFS, or SMB; however, in many cases, the delay is minor.
Remote Network Access
In addition to providing remote command line and remote file transfer utilities,
SSH can provide access to remote networks, creating something similar to
a virtual private network (VPN). SSH can not only provide VPN functionally
in the typical sense of the word (PPP over SSH), but can also provide services
that many VPN users require, such as e-mail, file transfer, and Intranet services
with port forwarding. Also, using SSH as a VPN solution is far less expensive
than using a typical VPN solution. When considering any SOHO VPN appliance,
a VPN card in a current network device, or any full-scale VPN server/
device, the cost of any such device is not any different from the cost of most
other network devices, but far exceeds the cost of SSH server implementations.
SSH as a VPN solution not only provides access to services such as e-mail,
internal file servers, and Intranet services, but with the use of advanced tunneling,
it provides access to X11 services, remote applications, and remote
tunneling.
Secure Management
Many networks today adhere to poor management practices, leaving their
critical systems and devices vulnerable to management attacks. Many environments
secure network devices and operating systems and create a properly
segmented network perimeter, but then they connect to sensitive systems/
devices with poor management protocols over wide-open or nonexistent management
networks. The clear-text protocols mentioned earlier, such as Telnet,
FTP, and SNMP, are not the only poor management protocols in question, but
many management applications have not secured their communication appropriately
or have known issues identified with them. Older versions of certain
management applications such as pcAnywhere, Virtual Network Computer
(VNC), and Citrix have either had poor encrypted management protocols,
which were reversed through engineering, or do not require any type of
encrypted management for the sensitive communication. Furthermore, any
attacker can download the client version of these applications and attempt to
connect to the application’s agent with a captured or guessed username and
password. This assumes that there is no separate management network that
the attacker cannot access, which prevents him or her from connecting to any
agents. While separate management networks are ideal for safe and secure
management, implementation of out-of-band management networks is not
only very costly but adds a significant amount of complexity to a network.
SSH can be used as a secure management alternative by providing encrypted
communication for any type of system or device management. Not only does
SSH provide secure communication for remote command line management,
which is the most popular management method on most Unix systems; it provides
secure communication of graphic user interfaces (GUIs) with less secure
applications such as VNC. In addition, SSH can provide two-factor authentication
for all management methods by requiring a public key and password
for management access. As best practice, two-factor authentication should be
used for all management methods, as it reduces the number of brute-force
attacks, password-guessing attacks, and dependencies on passwords for security.
SSH can enforce two-factor authentication quite easily, which supports a
critical best practice in management security. Lastly, SSH can eliminate the need
for an out-of-band management network, removing a significant amount of cost
and adding administrative simplicity in managing the systems and devices.
The following list describes the advantages of using SSH for management:
■■ Encrypted management
■■ Encrypted GUI management with port forwarding (discussed further in
Chapter 6)
■■ Significant cost savings
■■ Elimination of separate out-of-band management networks
■■ Added simplicity
■■ Two-factor authentication
Proxy Services
SSH can also be used to secure proxy services. Proxy servers have been identified
to contain established benefits to which SSH can add value. Deploying
SSH as a proxy service to access remote systems, devices, and applications in a
safe and easy manner is one of the strongest, but most unused, benefits of SSH.
SSH proxies can work with traditional proxy services such as SOCKS in order
to secure the application from end to end. A SOCKS server can be set up in an
environment and tunnel traffic via SSH. This setup allows remote applications
such as SQL, Oracle, FTP, HTTP, and MySQL to be available with client applications
such as SQL*PLUS and Query Analyzer over a secure channel.
SOCKS and SSH proxies can eliminate the need for an abundance of port
forwarding, as discussed in Chapter 9, and can provide secure access to applications
that may not be available from the network perimeter.
Unlike the use of Secure Sockets Layer (SSL) in encrypted Web traffic
(denoted by the HTTPS (Hyper-text Transfer Protocol over SSL) prefix in URLS),
SSH proxies can be used in a couple of ways to secure Web traffic over hostile
networks, such as the Internet or wireless networks. SSH proxies can be used
to connect to remote Web servers running on internal networks, by using HTTP
tunneling over SSH, over the Internet. This function adds application security
and Web security when internal systems are accessed from remote sites.
Client/Server Architecture for SSH
SSH uses client/server architecture in its implementation. An SSH server can
be deployed and allow several SSH clients to connect to it. The architecture is
not unlike any other client/server architecture, where the server portion of the
program is running a daemon or service that usually listens on port 22. SSH
does provide the ability for the daemon/service to listen on any port; however,
it must be listening on a TCP connection. SSH has a configuration file, where
the different options can be configured, such as password/public key authentication,
port options, and home directories. SSH clients just need to know the
IP address of the SSH server (or hostname) and the port on which it is listening,
such as port 22. Based on the configuration of the SSH server, such as login
requirements, the client just needs to authenticate to the server with the predefined
requirements and get access to the session, whether it is SSH or the
built-in SFTP functionality. Figure 1.6 shows a very simple example of the SSH
architecture
As shown in Figure 1.6, the SSH process is as follows:
■■ The SSH client on the left provides authentication to the SSH server on
the right. In the initial connection, the client receives a host key of the
server; therefore, in all subsequent connections, the client will know it is
connecting to the same SSH server. This places less emphasis on the IP
address of the SSH server, which can be easily spoofed, and more
emphasis on the host key of the server, which cannot be spoofed very
easily.
■■ The SSH server determines if the client is authorized to connect to the
SSH service by verifying the username/password or public key that the
client has presented for authentication. This process is completely
encrypted.
■■ If the SSH server authenticates the client and the client is authorized,
the SSH session begins between the two entities. All communication is
completely encrypted.
The client/server architecture for SSH provides the ability for clients to have
a single source for authentication and/or authorization. The single source for
authentication/authorization allows access only to the SSH service, while
access to various other services such as e-mail, intranets, extranets, and IRC
requires further authentication. Also, with the use of SSH proxies described
previously, a single source of authentication can provide access to applications
without the need for more usernames and passwords.
SSH’s Encryption Architecture
One of the many benefits of SSH is that it provides a fully encrypted protocol
for transferring information, but what is the encryption architecture that SSH
uses, and how is it deployed? This book does not explore in detail the encryption
algorithms used or how they are implemented in SSH (since optimization
and implementation are the focuses of this book), but I do briefly examine the
architecture in order to provide some background knowledge of its deployment.
SSH’s implementation architecture is just as flexible as the protocol itself.
SSH is compatible with the major encryption algorithms used today, including
the following:
■■ 3DES
■■ Blowfish
■■ Twofish (128 and 192)
■■ AES (128, 192, and 256)
■■ Arc Four
■■ CAST
■■ DES
■■ RC4
Any of the preceding encryption algorithms can be used for the ciphers for
the SSH connection. Most of the ciphers are well supported, but the use of DES
is strongly discouraged for the more secure 3DES option.
In addition to the preceding cipher algorithms, SSH offers Message Authentication
Code (MAC) algorithm hashes. Two of the choices supported in most
SSH implementations are MD5 and SHA1. MAC algorithm hashes are used for
data integrity. Data transferred from one entity to another is hashed with a
unique cryptographic signature, differentiating it from other data. The cryptographic
signature, generated with MD5 or SHA1 hashes, does not change
under any circumstances from one entity to the next. This ensures that the
entity receiving the data has obtained it without any modification, tampering,
or general abuse by unauthorized entities.
Basic Miscues with SSH
Many protocols used in enterprise networks have several security issues. SSH
is no different. SSH offers a wide variety of solutions, but it is important to
mention that SSH has had security issues, including severe issues that may
result in remote access to unauthorized users. I do not discuss all the security
issues associated with OpenSSH or other variants of SSH. I do, however,
encourage awareness that SSH, like any program or service, needs to be
patched on a regular basis. Inform your internal patch management process
and network operations personnel to patch and monitor SSH services on a regular
basis.
Some of the security issues identified with SSH involve buffer overflows,
incorrect X11 forwarding, weak Challenge/Responses handling, remote information
leakage, and privilege escalation. For more information, visit the following
URL for OpenSSH security problems: www.openssh.com/security.html.
Types of SSH Clients/Servers
SSH clients/servers come in a variety of packages. Following is a short summary
of the organizations and products mentioned throughout this book.
SSH Servers
■■ OpenSSH (www.openssh.com)
■■ OpenSSH is a free version of the SSH protocol suite. OpenSSH
servers and clients are available for both Unix and Windows.
■■ OpenSSH has been ported to Windows with the popular CYGWIN
utility. The project was created by Network Simplicity (www
.networksimplicity.com) and has been adopted by the following site:
http://lexa.mckenna.edu/sshwindows/.
■■ SSH2 (www.ssh.com)
■■ SSH2 is a commercial version of SSH, with required license fees for
commercial use (noncommercial use is free). Commercial SSH
clients/servers are available for both Windows and Unix systems.
VanDyke Software (www.vandyke.com)
■■ VanDyke Software makes a commercial version of SSH, with required
license fees for usage. Commercial SSH servers (VShell) and clients
(SecureCRT) are available for the Windows operating system.
SSH Clients
■■ Commerical SSH
■■ OpenSSH
■■ PuTTY
■■ Secure-CRT
■■ MindTerm—SSH over Java with Web browsers
■■ WinSCP
Basic Setup of SSH
This section focuses on setting up an SSH server in both a Unix and Windows
environment. The setup creates a base SSH server install, based on the operating
system of your choice, which enables the discussion of various SSH features
that appear throughout this book. The following lists the types of
implementations demonstrated:
■■ OpenSSH on Unix (Red Hat Linux 8.0 and OpenBSD 3.1)
■■ OpenSSH on Windows (Windows 2000 Server)
■■ Commercial SSH on Unix (Red Hat Linux 8.0 and OpenBSD 3.1)
■■ Commercial SSH on Windows (Windows 2000 Server)
■■ VShell SSH server on Windows (Windows 2000 Server)
Many operating systems, such as OpenBSD, are loaded with OpenSSH by
default. For the purposes of this section, I assume that your system has not
been pre-loaded with any type of an SSH server. If you have a machine that
already has the SSH service/daemon listening, feel free to skip this section.
OpenSSH
The following paragraphs describe the prevalent servers using OpenSSH.
Red Hat Linux 8.0
The following is a step-by-step procedure to install SSH on Red Hat 8.0.
RPM-Based Implementation
After the full installation of a Red Hat 8.0 server, use your favorite FTP client,
such as the command line client or built-in Web browser FTP functionality,
to download the latest RPM (Red Hat Package Manager) from ftp://ftp5.usa
.openbsd.org/pub/OpenBSD/OpenSSH/portable/rpm/RH80. I will be using
version 3.5 (openssh-3.5p1-1.i386.rpm). Download the RPM to the directory of
your choice; I recommend /usr/local/src. Once the file has been downloaded,
follow these directions:
1. From a shell, change directories to the location where the OpenSSH
RPM was downloaded:
# cd /usr/local/src
2. Install the OpenSSH RPM:
# rpm –i openssh-3.5p1-1.i386.rpm
To start the daemon, change to the installation directory and start the service:
# cd /usr/sbin
# ./sshd –p 22
Note, the –p option is not needed if you are using the default port (22).
You should now have the SSH server running on port 22 on your Red Hat
8.0 machine. To confirm this, type netstat –an and you should see the screen
Notice that all the interfaces, denoted by 0.0.0.0, are listening on port 22,
which is SSH.
Package-Based Implementation
After the full installation of a Red Hat 8.0 server, use your favorite FTP client,
such as the command line clients or built-in Web browser FTP functionality, to
download the latest package from ftp://ftp3.usa.openbsd.org/pub/OpenBSD/
OpenSSH/portable/openssh03.5p1.tar.gz. I will be using version 3.5 (openssh-
3.5p1.tar.gz). Download the package to the directory of your choice; I recommend
/usr/local/src. Once the file has been downloaded, implement the following
directions:
1. From a shell, change directories to the location where the OpenSSH
package was downloaded:
# cd /usr/local/src
2. Unzip the tarball using gunzip:
# gunzip –c openssh-3.5p1.tar.gz | tar xvf –
3. Change directories to SSH:
# cd openssh-3.5p1
4. Configure the object file and the dependencies:
# ./configure
5. Make the binary:
# make
# make install
You’re done!
To start the daemon, change to the installation directory and start the service:
# cd /usr/local/src/ssh
# ./sshd –p 22
Note, the –p option is not needed if you are using the default port (22).
You should now have the SSH server running on port 22 on your Red Hat
8.0 machine. To confirm this, type netstat –an and you should see the same
results as in Figure 1.7. Notice that all the interfaces, denoted by 0.0.0.0, are
listening on port 22, which is SSH.