Enter the secure shell
Turn remote login from security hole to security strength with ssh
February 1998
![[Next story]](/sunworldonline/icons/tb-next.gif){kind=icon}
![[Table of Contents]](/sunworldonline/icons/tb-toc.gif){kind=icon}
![[Search]](/sunworldonline/icons/tb-search.gif){kind=icon}
|
|
Enter the secure shellTurn remote login from security hole to security strength with ssh |
February 1998
|
Authentication and encryption for the rest of us? This month begins a two-part exploration of ssh, the secure shell package. It adds authentication and encryption to the r* tools (rsh, rcp, and rlogin). ssh converts a security hole into a security strength.Also this month, in The Bookstore, a review of the book, Applied Cryptography by Bruce Schneier, good news on the security bug front in The Buglist, and information on commercial security tools. And don't forget the the Solaris Security FAQ for all your Solaris security information needs.
Cisco's Steve Acheson, who knows a thing or two about security, co-authors this month's column. (2,700 words)
 Mail this article to a friend |
nfortunately,
there is more truth than some would like in the aphorism "security is inversely proportional to
convenience." It is a natural tendency of system
administrators, and even managers, to decrease security in favor of easy
access. The more security you have, the
harder it is to do your job. Even at sites where security matters, such as banks, the choices
are not easy. For instance, should security be increased even though it delays
a trader's problem resolution?
Most of us like the convenience of the Berkeley remote (r*) tools (rsh, rcp, rlogin) for rapid access between machines. The problem is that these tools are, shall we say, security challenged. They rely on host names or IP addresses for authentication. These addresses are inherently insecure. Break into a client, and you've broken into a server or multiple servers. Bring in a laptop, configure it to have the IP address of a trusted machine, and the chances are good that the new machine will be recognized as the "correct" system.
For r* tools to be used in a secure environment, they must have better authentication. By encrypting their data channels, users can maintain privacy, passwords can be hidden from sniffers, and even returned data such as X connections can be secured. Welcome to the Secure Shell (ssh).
|
|
|
|
|
Enter the secure shell
ssh was designed to be a drop-in replacement for the r* tools (in
the form of ssh, scp, and slogin), but with the added features of
strong end-to-end encryption, improved user and host authentication,
and TCP and X11 forwarding. ssh uses RSA's patented public key/private key technology to do host authentication. For user
authentication there are several different options, including Kerberos and SecureID as well as RSA. ssh even supports
.rhosts user authentication if the RSA based host authentication
succeeds.
To establish trust, Unix normally requires that the /etc/hosts.equiv and $HOME/.rhosts files contain the names or IP addresses of remote hosts
that the local host trusts. The r* tools then depend on the IP address, or
the name-to-IP translation and the IP address, to be trustworthy.
Unfortunately, security based on IP addresses just isn't enough, which is
why ssh uses RSA for host authentication.
When ssh is installed on a host, a public and private key pair is generated
for that host and stored in the /etc directory. The private key is
restricted to root access only, while the public key is world readable.
These keys are used to authenticate the host to another host with whom a
connection is being established. The public key of the local host needs to
be added to the /etc/ssh_known_hosts file on all remote systems that the
current host wants to access via .rhosts or hosts.equiv. Alternatively, a
user can add the remote host's public key to her $HOME/.ssh/known_hosts file
on the remote host they want to access.
RSA authentication uses the property that anything encrypted with the public key of a key pair can be decrypted only with the private key. The reverse is also true. A second property is that it is not possible to derive the private key from the public key or vice versa.
Thus a host generates a random string, and encrypts it with the public key of a remote host. If the remote host correctly decrypts the string and returns it, it is considered authenticated. By forcing both ends to verify their identity, ssh provides protection against three common spoofing attacks: DNS, IP and routing spoofing.
Once the hosts are authenticated, user authentication can take place. This
consists of a series of attempts by the local host to provide
authentication for the user to the remote host. ssh has two primary
methods of authentication. The first is RsaAuthentication, in which the users
are authenticated via the .rhosts and hosts.equiv files just as with the
Berkeley tools. This is the simplest method, and the easiest for users to
take advantage of.
The second method requires that the user generate a public and private key pair of her own, and to distribute the public key to all hosts she want to connect to. The private key is stored in an encrypted file in the user's home directory. If neither of these methods is setup, ssh will prompt for a password (even for file copying using scp, an improvement over rcp).
ssh encryption
In addition to authentication, ssh also provides several options for
encryption. IDEA is the default cipher for encryption, but DES,
3DES, and blowfish are also available. ssh employs symmetric key
encryption for the data transfer because public key encryption is
too computationally expensive. The client generates a random string
for use as the symmetric key and sends it to the server encrypted
with the server's public key, so someone eavesdropping can't get the
key. The encryption is automatic, end-to-end, and is started
immediately after host authentication, but before user
authentication. This way, even if the user must enter her password,
it is sent over a secure channel. No configuration is necessary to
enable encryption. In fact, it can't be disabled, except at compile
time.
Once the session is established, ssh will check for the presence of the DISPLAY environment variable and will setup X11 forwarding automatically if found. This is accomplished by creating a pseudo server on the remote host and setting the remote DISPLAY variable to point to the pseudo server. This feature makes using ssh in combination with X11 extremely convenient.
It should be noted that while the session (and therefore all X11
traffic) is encrypted, X authentication still relies on the
.Xauthority file located in the user's home directory.
If this file is compromised, so too is the entire X server and all
clients connected to it.
This situation can be improved via an Xnest server. It can be used to break up the display into discrete zones of contact. Xnest is a middle layer application that acts as a client the to real X server and as a server to all X clients directed at it. It controls the windows and graphics requests on behalf of the client to the server. For more information on Xnest, see the documentation for X11R6.3.
Another convenient feature of ssh is the ability to forward arbitrary TCP ports over the secure connection. ssh supports forwarding client local ports to a second remote system via the secure connection to the remote server, as well as forwarding ports from the remote server to a second local system.
This might be better explained with an example: Consider three
hosts, X, Y, and Z. Host X is the client and establishes a session
with Y, the server, via ssh. A port on X, say 1999 is setup to be
forwarded to another port on the remote host Z, say 23. The port is
forwarded over the encrypted tunnel to Y, which then sends it
unencrypted to host Z's port 23. Thus the command telnet
localhost 1999 would result in a telnet connection being
established with host Z, passing over the encrypted tunnel to Y.
ssh -L 1999:Z:23 Y sleep 100 |
The sleep command is necessary to give ssh something to do on the remote system while waiting until you make a connection. Once the sleep has run out, ssh will wait for the forwarded port to close before exiting. An alternative program could be xclock, which would keep the forward around until xclock is closed.
Forwarding ports from the remote server system would result in a port on the server, Y, say 1080, being forwarded to the host Z's port 80, over the encrypted tunnel from host X.
ssh -R 1080:Z:80 Y sleep 100 |
This can be viewed as a pseudo proxy capability, or tunneling IP, and a potential security hole in firewalls that allow ssh through. The firewall or its implementer may think they are allowing just the ssh communications to pass, but potentially, they may allow arbitrary communications between the local system and any remote system.
Top wrapper security
For added security control, ssh has support for Wietse Venema's tcp
wrapper package. Both the client and server programs use the
/etc/hosts.allow and /etc/hosts.deny files
to control connections. The server uses the wrappers to control all
incoming connections and ports forwarded through the server.
The ssh and slogin clients can use the wrappers to control port
forwarding back from the remote host. This is especially important
when ssh is allowed through a firewall, either incoming or
outgoing. the sshdfwd-port# or sshdfwd-servicename entry in the
/etc/hosts.allow file is used to control the forwarding
of ports.
As useful as ssh sounds, keep in mind that it does not solve all host-based security problems. For instance, standard NFS is just as insecure as ever and can be susceptible to sniffing and host IP spoofing. But for secure, convenient remote host login, ssh is quite effective. It is possible that, over time, SKIP (Simple Key management for Internet Protocols) and its fellow protocols will overtake ssh because they are more general-purpose and should become ubiquitous. But for now, ssh is holding its own.
Unfortunately, even security tools have security holes. Before you decide to add yet another tool to your systems, you should decide if the benefits it will bring outweigh the cost, effort, and security problems it could introduce. For instance, CERT just released a security advisory against ssh. With patches, as with life, you need to either keep up or you fall behind.
ssh availability
ssh is freely available for non-commercial use from ftp://ftp.cs.hut.fi/pub/ssh.
If you need information on commercial or non-Unix clients, visit Datafellows at http://www.Datafellows.com, the vendor of the commercial versions of ssh. The Windows 95/NT commercial client versions do not have a file transfer capability and use a proprietary terminal emulator. The commercial Unix version doesn't have support for the IDEA cipher (due to patent restrictions). Evaluation downloads are available.
There are several free ports for Windows 95 and NT but these are not totally stable or complete. See http://guardian.htu.tuwien.ac.at/therapy/ssh and http://public.srce.hr/~cigaly/ssh. There is an OS/2 version (still bound by ssh copyright) for non-commercial use at ftp://ftp.cs.hut.fi/pub/ssh/os2. An independently developed version for the PalmPilot is available at http://www.isaac.cs.berkeley.edu/pilot. If you happen to have an Amiga, there are a couple of different versions for you. See http://www.lysator.liu.se/~lilja/amigassh for one, and the other is available from Aminet.
Finally, there is an extensive amount of documentation available on the net that you may want to explore. In addition to the comprehensive man pages available with ssh, check out the ssh home page. The FAQ has some good answers to the common questions. Kimmo Suominen has written a good tutorial to get you started using ssh. The best newsgroup is comp.security.ssh. The mailing list is hosted at clinet.fi. To subscribe, send subscribe ssh in the body of a message to majordomo@clinet.fi. Links to these documents are all provided in the Resources section, below.
In part II of this column, we'll go over the details of installing ssh under Solaris, and give some security tips for administrators.
The Bookstore
If you are seriously interested in computer security, then Applied Cryptography by Bruce
Schneier is a must-read. The book is exceptionally literate and accessible.
Schneier keeps your attention with statements like, "It is insufficient to
protect ourselves with laws; we need to protect ourselves with
mathematics."
Applied Cryptography |
The book is both an introduction to the field and a comprehensive reference. Although some areas could have been covered in more detail, that might have turned Applied Cryptography into an encyclopedia (the book is 758 pages long). Schneier manages a fine balance between conveying information and covering all important topics. The five parts of the book cover cryptographic protocols, including public key, digital signatures, key exchange, and digital cash; cryptographic techniques such as key length, key management, algorithm types, and hardware encryption; cryptographic algorithms including block ciphers like DES, public key, key exchange, and identification schemes; the real world including example algorithms and politics; and source code.
Schneier didn't seem to have enough space to include source code as often as we'd have liked it. Floppy disks with source code are available for $40 a set, but only within the U.S. and Canada due to governmental export restrictions.
The book references other publications extensively. Which makes it a terrific starting point for further exploration of cryptography. Unfortunately, all the reference numbers interfere with the book's flow.
Still, Schneier manages to maintain interest in spite of all the references. For example, algorithms are not just presented as mathematics. Their history, development, politics, and attack resistance are included. And the algorithms themselves are covered in detail through figures and walk-throughs. The coverage of DES, for instance, states that the publication of the algorithm was probably a mistake by the NSA. If they had known it would be published such that others could implement it in software, they probably never would have help develop it and declare it secure. "It was no accident that the next standard algorithm, Skipjack, was classified," Schneier writes. (Skipjack is the algorithm for the Clipper chip.)
If you want to understand encryption, how it is used or how to use it, this is the book. It is one of those books that you can pick up and start reading at any point, and have a hard time putting down. Definitely more than you would expect for a book on cryptography.
The Buglist
For once, there is some good news on the bug front. Kudos to the Apache team for the CERT
bulletin reporting some bugs in their web server. There's nothing
special about the bugs, except for the fact that they were found, reported,
and fixed as part of a code review. Rather than waiting for crackers to
find and exploit the bugs, the team decided to clean house and get
proactive about finding bugs. If only all software developers would do
this, we could all rest easier.
Sun has released another spate of security patches over the past month. The single most useful URL is Sunsolve's Public Patch Page. It has nice summaries of all recommended and security patches, as well as links to the appropriate patch clusters. It's even updated nightly. Oddly, it only covers through Solaris 2.5. So if you're running 2.5.1 or 2.6, you still have to patch your system the old-fashioned way by downloading and installing individual patches. If you don't mind being a month or so behind the curve you can use the CD-ROM version of the sunsolve database, which includes patch clusters and cluster installation tools. The current (December) CD-ROM set includes a 22MB Solaris 2.5.1 patch cluster.
Letters
Mike Bass writes:
Peter,
Back in July you wrote an article about Unix security,
"The SeOS security blanket,"
suggesting that, rather than rewrite Unix, a product called SeOS should be used. Have you
worked with this product since then or installed at customer sites, and if so,
what is the feedback? Are there competitive products and/or are the Unix
venders including similar functionality?
Thanks,
Mike.
Yes, I'm currently working with the latest version of SeOS. I still recommend it. It's a complex product, but very powerful. It can control password use, program execution, setuid use, incoming and outgoing network connections, and even as a sudo replacement. Other tools are available, depending on what your needs are. SeOS is the best at locking down a system. Platinum resells it at their product. BoKs makes a package for secure authentication, and password control and was described in the November 1997 security column. Axent makes a few products for security problem scanning. ISS makes a great network scanner that will analyze systems for network vulnerabilities. I hope to review the products from both of those in an upcoming column.
Readers, what tools are you using? Let us know what your favorites are, and
what aspect of security they address.
|
|
Resources
About the author
![[Peter Galvin's photo]](/sunworldonline/icons/galvin.gif){kind=icon}
Peter Galvin is chief technologist
for Corporate Technologies Inc., a systems integrator and VAR. He is also adjunct system planner for the Computer Science Department at Brown University, and
has been program chair for the past four SUG/SunWorld conferences.
As a consultant and trainer, he has given talks and tutorials
worldwide on the topics of system administration and security. He
has written articles for Byte and Advanced Systems
(SunWorld) magazines, and the Superuser newsletter.
Peter is co-author of the best-selling Operating Systems
Concepts textbook. Reach Peter at peter.galvin@sunworld.com.
Steve Acheson is currently a senior computer security analyst at Cisco Systems, where he is responsible for network and system security, including designing internal security architecture and external/firewall access.
Prior to working for Cisco, Steve managed security for NASA's Numerical Aerospace Simulations facility at Ames Research Center. Steve has worked in the field as a system administrator and network engineer for over 10 years. Reach Steve at steve.acheson@sunworld.com.
|
|
|
|
![[(c) Copyright Web Publishing Inc., and IDG Communication company]](/sunworldonline/icons/b-copyright98.gif){kind=icon}
If you have technical problems with this magazine, contact webmaster@sunworld.com
URL: http://www.sunworld.com/swol-02-1998/swol-02-security.html
Last modified: