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.
The Unix programs rsh, rlogin, and rcp--collectively known as the r-commands --are the direct ancestors of the SSH clients ssh, slogin, and scp. The user interfaces and visible functionality are nearly identical to their SSH counterparts, except that SSH 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 Macintosh OS 9).
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 anymore. Install SSH and be happy.
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. GnuPG is a more powerful successor to PGP with less-restrictive licensing.
SSH incorporates some of the same encryption algorithms as PGP and GnuPG, 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: Tectia can optionally use PGP keys for authentication. [5.4.5]
More PGP and GnuPG information is available at http://www.pgp.com/ and http://www.gnupg.org/, respectively.
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 networkwide 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 easily secure most TCP/IP-based programs via a technique called port-forwarding. 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. 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 both Kerberos and SSH sound good, you’re in luck: they’ve been integrated. [11.5.2] More information on Kerberos can be found at http://web.mit.edu/kerberos/www/.
Internet Protocol Security (IPSEC) is an 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 Chapter 11 we discuss 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/html.charters/ipsec-charter.html.
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 on a portable storage device and hope that you can get the key into whatever machine you need to use.
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/.
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/.
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.
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, email clients like Microsoft Outlook and Mozilla Mail can connect to POP, IMAP, and SMTP servers using SSL. For more stunnel information, see http://www.stunnel.org/.
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.
Get SSH, The Secure Shell: The Definitive Guide, 2nd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
