1.6. Related Technologies
SSH is popular and convenient, but we certainly don't claim it
is the ultimate security solution for all networks. Authentication,
encryption, and network security originated long before SSH and have
been incorporated into many other systems. Let's survey a few
representative systems.
1.6.1. rsh Suite (R-Commands)
The Unix programs
rsh,
rlogin,
and
rcp -- collectively
known as the
r-commands -- are the direct
ancestors of the SSH1 clients
ssh,
slogin, and
scp. The user
interfaces and visible functionality are nearly identical to their
SSH1 counterparts, except that SSH1 clients are secure. The
r-commands, in contrast, don't encrypt their connections and
have a weak, easily subverted authentication model.
An r-command server relies on two mechanisms for security: a network
naming service and the notion of
"
privileged" TCP ports. Upon
receiving a connection from a client, the server obtains the network
address of the originating host and translates it into a hostname.
This hostname must be present in a configuration file on the server,
typically
/etc/hosts.equiv, for the server to
permit access. The server also checks that the source TCP port number
is in the range 1-1023, since these port numbers can be used only by
the Unix superuser (or root uid). If the connection passes both
checks, the server believes it is talking to a trusted program on a
trusted host and logs in the client as whatever user it requests!
These two security checks are easily
subverted.
The translation of a network address to a hostname is done by a
naming service such as Sun's
Network Information Service (NIS) or
the Internet
Domain Name System (DNS). Most
implementations and/or deployments of NIS and DNS services have
security holes, presenting opportunities to trick the server into
trusting a host it shouldn't. Then, a remote user can log into
someone else's account on the server simply by having the same
username.
Likewise, blind trust in privileged TCP ports represents a serious
security risk. A cracker who gains root privilege on a trusted
machine can simply run a tailored version of the
rsh client and log in as any user on the server
host. Overall, reliance on these port numbers is no longer
trustworthy in a world of desktop computers whose users have
administrative access as a matter of course, or whose operating
systems don't support multiple users or privileges (such as
Windows 9x and the Macintosh).
If user databases on trusted hosts were always synchronized with the
server, installation of privileged programs (setuid root) strictly
monitored, root privileges guaranteed to be held by trusted people,
and the physical network protected, the r-commands would be
reasonably secure. These assumptions made sense in the early days of
networking, when hosts were few, expensive, and overseen by a small
and trusted group of administrators, but they have far outlived their
usefulness.
Given SSH's superior security features and that
ssh is backward-compatible with
rsh (and
scp with
rcp), we see no compelling reason to run the
r-commands any more. Install SSH and be happy.
1.6.2. Pretty Good Privacy (PGP)
PGP is a popular encryption program available for many computing
platforms, created by Phil Zimmerman. It can authenticate users and
encrypt data files and email messages.
SSH
incorporates some of the same encryption algorithms as PGP, but
applied in a different way. PGP is file-based, typically encrypting
one file or email message at a time on a single computer. SSH, in
contrast, encrypts an ongoing session between networked computers.
The difference between PGP and SSH is like that between a batch job
and an interactive process.
TIP:
PGP and SSH are related in another way as well: SSH2 can optionally
use PGP keys for authentication. [Section 5.5.1.6, "PGP authentication"]
More PGP information is available at
http://www.pgpi.com/.
1.6.3. Kerberos
Kerberos
is a
secure authentication system for environments where networks may be
monitored, and computers aren't under central control. It was
developed as part of Project Athena, a wide-ranging research and
development effort at the Massachusetts Institute of Technology
(MIT). Kerberos authenticates users by way of
tickets,
small sequences of bytes with limited lifetimes, while user passwords
remain secure on a central machine.
Kerberos and SSH solve similar problems but are quite different in
scope. SSH is lightweight and easily deployed, designed to work on
existing systems with minimal changes. To enable secure access from
one machine to another, simply install an SSH client on the first and
a server on the second, and start the server. Kerberos, in contrast,
requires significant infrastructure to be established before use,
such as administrative user accounts, a heavily secured central host,
and software for network-wide clock synchronization. In return for
this added complexity, Kerberos ensures that users' passwords
travel on the network as little as possible and are stored only on
the central host. SSH sends passwords across the network (over
encrypted connections, of course) on each login and stores keys on
each host from which SSH is used. Kerberos also serves other purposes
beyond the scope of SSH, including a centralized user account
database, access control lists, and a hierarchical model of trust.
Another difference between SSH and Kerberos is the approach to
securing client applications. SSH can be easily integrated with
programs that use
rsh in the background, such as
Pine, the popular mail reader. [
Section 11.3, "Pine, IMAP, and SSH"] Configure
it to use
ssh instead of
rsh,
and the program's remote connections are transparently secure.
For programs that open direct network connections, SSH's
port-forwarding feature provides another convenient form of
integration. Kerberos, on the other hand, contains a set of
programming libraries for adding authentication and encryption to
other applications. Developers can integrate applications with
Kerberos by modifying their source code to make calls to the Kerberos
libraries.
[4] The MIT Kerberos distribution
comes with a set of common services that have been
"
kerberized," including secure
versions of
telnet,
ftp, and
rsh.
If the features of Kerberos and
SSH both sound good, you're in
luck: they've been integrated. [
Section 11.4, "Kerberos and SSH"]
More information on Kerberos can be found at:
http://web.mit.edu/kerberos/www/
http://nii.isi.edu/info/kerberos/
1.6.4. IPSEC
Internet Protocol
Security (IPSEC) is an evolving Internet standard for network
security. Developed by an IETF working group, IPSEC comprises
authentication and encryption implemented at the IP level. This is a
lower level of the network stack than SSH addresses. It is entirely
transparent to end users, who don't need to use a particular
program such as SSH to gain security; rather, their existing insecure
network traffic is protected automatically by the underlying system.
IPSEC can securely connect a single machine to a remote network
through an intervening untrusted network (such as the Internet), or
it can connect entire networks (this is the idea of the
"Virtual Private Network," or VPN).
SSH is often quicker and easier to deploy as a solution than IPSEC,
since SSH is a simple application program, whereas IPSEC requires
additions to the host operating systems on both sides if they
don't already come with it, and possibly to network equipment
such as routers, depending on the scenario. SSH also provides user
authentication, whereas IPSEC deals only with individual hosts. On
the other hand, IPSEC is more basic protection and can do things SSH
can't. For instance, in
Section 11.2, "FTP Forwarding", we discuss in detail the difficulties of
trying to protect the FTP protocol using SSH. If you need to secure
an existing insecure protocol such as FTP, which isn't amenable
to treatment with SSH, IPSEC is a way to do it.
IPSEC can provide authentication alone, through a means called the
Authentication Header (AH), or both authentication and encryption,
using a protocol called
Encapsulated Security Payload
(ESP). Detailed information on IPSEC can be found at:
http://www.ietf.org/ids.by.wg/ipsec.html
1.6.5. Secure Remote Password (SRP)
The
Secure Remote Password (SRP) protocol,
created at Stanford University, is a security protocol very different
in scope from SSH. It is specifically an authentication protocol,
whereas SSH comprises authentication, encryption, integrity, session
management, etc., as an integrated whole. SRP isn't a complete
security solution in itself, but rather a technology that can be a
part of a security system.
The design goal of SRP is to improve on the security properties of
password-style authentication, while retaining its considerable
practical advantages. Using SSH public-key authentication is
difficult if you're traveling, especially if you're not
carrying your own computer, but instead are using other
people's machines. You have to carry your private key with you
on a diskette and hope that you can get the key into whatever machine
you need to use. Oops, you've been given an X terminal. Oh
well.
Carrying your encrypted private key with you is also a weakness,
because if someone steals it, they can subject it to a dictionary
attack in which they try to find your passphrase and recover the key.
Then you're back to the age-old problem with passwords: to be
useful they must be short and memorable, whereas to be secure, they
must be long and random.
SRP provides strong two-party mutual authentication, with the client
needing only to remember a short password which need not be so
strongly random. With traditional password schemes, the server
maintains a sensitive database that must be protected, such as the
passwords themselves, or hashed versions of them (as in the Unix
/etc/passwd and
/etc/shadow
files). That data must be kept secret, since disclosure allows an
attacker to impersonate users or discover their passwords through a
dictionary attack. The design of SRP avoids such a database and
allows passwords to be less random (and therefore more memorable and
useful), since it prevents dictionary attacks. The server still has
sensitive data that should be protected, but the consequences of its
disclosure are less severe.
SRP is also intentionally designed to avoid using encryption
algorithms in its operation. Thus it avoids running afoul of
cryptographic export laws, which prohibits certain encryption
technologies from being shared with foreign countries.
SRP is an interesting technology we hope gains wider acceptance; it
is an excellent candidate for an additional authentication method in
SSH. The current SRP implementation includes secure clients and
servers for the Telnet and FTP protocols for Unix and Windows. More
SRP information can be found at:
http://srp.stanford.edu/
1.6.6. Secure Socket Layer (SSL) Protocol
The
Secure Socket Layer (SSL) protocol
is an authentication and encryption technique providing security
services to TCP clients by way of a Berkeley sockets-style API. It
was initially developed by Netscape Communications Corporation to
secure the HTTP protocol between web clients and servers, and that is
still its primary use, though nothing about it is specific to HTTP.
It is on the IETF standards track as RFC-2246, under the name
"TLS" for
Transport Layer Security.
An SSL participant proves its identity by a
digital
certificate, a set of cryptographic data. A
certificate indicates that a trusted third party has verified the
binding between an identity and a given cryptographic key. Web
browsers automatically check the certificate provided by a web server
when they connect by SSL, ensuring that the server is the one the
user intended to contact. Thereafter, transmissions between the
browser and the web server are encrypted.
SSL is used most often for web applications, but it can also
"tunnel" other protocols. It is secure only if a
"trusted third party" exists. Organizations known as
certificate
authorities (CAs) serve this function. If a
company wants a certificate from the CA, the company must prove its
identity to the CA through other means, such as legal documents. Once
the proof is sufficient, the CA issues the certificate.
For more information, visit the OpenSSL project at:
http://www.openssl.org/
1.6.7. SSL-Enhanced Telnet and FTP
Numerous TCP-based communication programs
have been enhanced with SSL, including
telnet
(e.g., SSLtelnet, SRA telnet, SSLTel, STel) and
ftp (SSLftp), providing some of the functionality
of SSH. Though useful, these tools are fairly single-purpose and
typically are patched or hacked versions of programs not originally
written for secure communication. The major SSH implementations, on
the other hand, are more like integrated toolsets with diverse uses,
written from the ground up for security.
1.6.8. stunnel
stunnel
is an SSL tool created by
Micha Trojnara of Poland. It adds SSL
protection to existing TCP-based services in a Unix environment, such
as POP or IMAP servers, without requiring changes to the server
source code. It can be invoked from
inetd as a
wrapper for any number of service daemons or run standalone,
accepting network connections itself for a particular service.
stunnel performs authentication and authorization
of incoming connections via SSL; if the connection is allowed, it
runs the server and implements an SSL-protected session between the
client and server programs.
This is especially useful because certain popular applications have
the option of running some client/server protocols over SSL. For
instance, both Netscape Communicator and Microsoft Internet Explorer
allow you to connect POP, IMAP, and SMTP servers using SSL. For more
stunnel information, see:
http://www.stanton.dtcc.edu/stanton/cs/admin/notes/ssl
1.6.9. Firewalls
A
firewall
is a hardware device or software program that prevents certain data
from entering or exiting a network. For example, a firewall placed
between a web site and the Internet might permit only HTTP and HTTPS
traffic to reach the site. As another example, a firewall can reject
all TCP/IP packets unless they originate from a designated set of
network addresses.
Firewalls aren't a replacement for SSH or other authentication
and encryption approaches, but they do address similar problems. The
techniques may be used together.
| | |
1.5. History of SSH | | 1.7. Summary |