More on mastering the secure shell We take you through the process of installing and configuring ssh -- command by command -- and list all the options you might want to change

March  1998

Last month we discussed the features, uses, and benefits of ssh. Now we'll go over the installation and configuration of ssh on a Sun Solaris machine. We'll cover some security considerations and possible solutions as well.

Also this month: In The Bookstore, we review Secrets of a Super Hacker by The Knightmare, in The Buglist a report by CERT on a bug in statd being used by crackers to gain root access over networks, and in Patches two tools available for patch management.

Cisco's Steve Acheson co-authors this month's column. (4,300 words)

Mail this article to a friend

sh is fairly easy to install on almost any Unix system. It uses gnu's autoconf to generate a configuration shell script. For the most part, it will determine everything it needs to know about your system and generate a set of "makefiles." You will probably want to override some of the options for your local setup.

To begin the install process, get the latest ssh distribution from the ftp site. As of this writing, the current version is at 1.2.22. Once you have the distribution, untar it in your local source tree. Using gnutar, the command would be:

gtar -xzvf ssh-1.2.22.tar.gz

This will create a directory, ssh-1.2.22, that contains all the necessary files to build ssh. Ssh comes with its own version of the gnu multiprecision library (gmp) that's been modified for its use. Ssh also incorporates the gnu compression library (zlib).

Now that you have your source untarred, cd into the ssh directory. If you are comfortable with the defaults you can simply start the configuration process now:

./configure

There are several options specific to configuration and operation. Here we'll address those that you'll likely need to change. The following command will show all the configuration options available:

./configure --help

Configure options
Here are the options you might want to change (and their defaults):

--prefix=<path>
(/usr/local)
--exec-prefix=<path> (--prefix's value)

These options tell configure the eventual top-level destination directory you want the programs and their supporting files installed into. --prefix determines where all of the files will go unless the --exec-prefix option is also given. --exec-prefix specifies where only the architecture-specific files will go. This allows you to have all of the common files shared across the network, but still have the binaries live in an architecture-specific place. The default value for --prefix is /usr/local. The default for --exec-prefix is whatever --prefix is set to. See the output from --help if you need more control of file destinations.

--x-includes=<path> (search)

--x-libraries=<path> (search)

Tells configure that the includes or libraries for X are located in the directory specified by <path>. Configure does a search for X, but these options can be used to override anything it finds.

--with-idea (default)
--without-idea

Tells configure not to include support for the IDEA cipher. IDEA requires a license for commercial use in most countries. Other ciphers can also be enabled/disabled, but IDEA is the only one with patent issues.

--with-login[=<path>] (no)

Tells configure to use /bin/login (or <path>) to finish the connection. Normally ssh does the login steps itself, but some sites have custom login programs and rather than hacking the same functionality into ssh itself, this allows them to run the custom login instead.

--with-rsh[=<path>]
--without-rsh
--program-transform-name='program' (no default)

This is used to tell ssh where the r* programs will be located when ssh needs to fall back to using rsh. Ssh is designed so that it can be installed in place of the existing r* programs, but will automatically switch back to using rsh if the remote host doesn't support ssh. For this to work, ssh needs to know the directory where rsh, rlogin, and rcp live.

If you decide to put the ssh binaries in the same location as the r* programs, you will need to create a new directory (renaming the binaries isn't enough) for the r* programs and move them there. Ssh will call them from this directory.

Use the --program-transform-name option to tell install how to modify the name of ssh during installation. The program will be passed to sed for execution during the installation.

For example:

./configure --with-rsh=/usr/bin/orig/rsh --program-transform-name='s/^s/r'

This assumes that you have created a directory, /usr/bin/orig, and copied rsh, rlogin, and rcp there. When you do a make install ssh will be installed as rsh and will call /usr/bin/orig/rsh when necessary.

Note: If you have previously installed ssh this way, you will need to specify the --with-rsh path, or ssh will find the older version of itself and complain.

--with-etcdir=<path> (/etc)

This is the directory that will contain the ssh system files. This is where the host keys, config files, etc., live.

--with-securid[=<path>] (no)

This enables support for Security Dynamics SecurID authentication. The optional path tells configure where to find the header files and the sdiclient.a library. See the README.SECURID that comes with the distribution. For more information on SecurID, see Resources below.

--with-tis[=<path>] (no)

This enables support for user authentication via the TIS firewall toolkit. The optional path tells configure where to find the header files and libraries. See the README.TIS that comes with the distribution. For more info on the TIS firewall toolkit, see Resources below.

--with-kerberos5[=<path>] (no)

If set, this option enables the support of Kerberos version 5 for user authentication. If no path is specified, configure will default to /usr/local for the top of the Kerberos install tree. The path, if specified, needs to be the top of the installed tree as it will append include and lib to the given path to find the header files and libraries necessary to support Kerberos. There is no documentation with the ssh distribution to help set up Kerberos support, so experience with Kerberos is suggested. For more information see the Kerberos FAQ link in Resources.

--with-libwrap[=<path>] (no)

This option enables support for the tcp_wrapper library. The optional path tells configure where to find the library if it's not in the local directory. The header file, tcpd.h, is searched for along the standard include path. There is no option to tell configure where to look for this file. We suggest creating a symbolic link to the library and header file in the current directory and letting configure find them there.

--with-socks (no)
--with-socks4[=<path>] (no)
--with-socks5[=<path>] (no)

Enables support for socks proxy. If you use the --with-socks option, configure will try to find the libsocks5 library first, then the version 4 libsocks library.

--with-rsaref[=<path>] (no)

This option tells configure to use the reference version of the RSA library instead of the included version. This is to avoid license issues in the U.S. For more information or to get a copy of the rsaref distribution see: ftp://ftp.rsa.com/rsaref.

Note: Configure expects the rsaref software to be in a directory called rsaref2 under the main directory. This is not the way the rsaref tar file unpacks by default. Create the rsaref2 directory, cd into it, and then unpack the archive.

--enable-group-writeability yes|no (no)

Normally sshd verifies that the user authentication files are only modifiable by the owner. Setting this option allows group write access to the files. This should be used with caution as it is a systemwide change.

--disable-server-port-forwardings (no)
--disable-client-port-forwardings (no)
--disable-server-x11-forwarding (no)
--disable-client-x11-forwarding (no)

These options disable arbitrary TCP port or X11 forwarding in either the server or client.

--disable-asm (no)

This option disables the use of the gnu multiprecision library, a set of optimized assembly routines specific to the hardware platform ssh is being compiled on. Configure will automatically determine the platform and use the assembly routines unless this option is given. This is often a good place to start debugging if the program hangs while generating keys.

Build it!
Now that you have your configuration options picked out, you need to run the configure program with those options:

./configure --with-rsh --prefix=/local --with-libwrap=. --with-rsaref
creating cache ./config.cache
checking host system type... sparc-sun-solaris2.5.1
checking cached information... ok
checking for gcc... gcc
checking whether the C compiler (gcc ) works... yes
[...]
checking whether to use libwrap... yes
checking whether to use rsaref... yes
[...]
creating ./config.status
creating Makefile
creating sshd.8
creating ssh.1
creating make-ssh-known-hosts.1
creating zlib-1.0.4/Makefile
creating config.h

Now that the configuration is done, type make, and then make install. If you aren't sure where everything is going to be installed, you can type make -n install, and it will show you what it's about to do.

Start it up
Once you have ssh installed, you need to start up the daemon. You also need to set up the daemon to start at boot time. You can have it started via inetd, but this isn't recommended due to the initial delay while the daemon starts up and generates a new server key. It's better to start the daemon standalone via the startup script on your system. On Solaris, place the script under /etc/init.d and link it into the startup directory rc3.d with an appropriate name. Go to http://sunsite.unc.edu/pub/packages/security/ssh/contrib/solaris-autostart for an example.

Server configuration: Command line options for sshd
Because many of sshd's command line options can also be set in its configuration file, we include only those available from the command line. Options for sshd include:

-d

Debug mode. This option tells the server not to go into the background and to generate verbose debugging output. This option can be useful if a bug is suspected in the server. For debugging client connection problems, use the ssh client's -v option instead.

-f <configuration file>

This option specifies the location and name of the configuration file. The default is /etc/sshd_config.

-i

This option tells ssh that its running under inetd. This isn't recommended as sshd needs to generate the server key before it communicates with the client, and this can cause a noticeable delay for the client.

Configuration file settings for sshd
The configuration file for sshd (/etc/sshd_config) allows you to set options that modify the operation of the daemon. The files contain keyword-value pairs, one per line, with keywords being case insensitive.

Here are the more important keywords, a complete listing is available in the man page for sshd.

AllowHosts pattern
AllowUsers pattern
AllowGroups pattern

These keywords define a set of hosts, users, or users in a primary group (user's default group) that are allowed to connect or login to the system. pattern is a space separated list of host, login, or group names and can contain wildcards (* and ?). No other systems or users are permitted access (tcp_wrappers is generally more useful than AllowHosts).

DenyHosts pattern
DenyUsers pattern
DenyGroups pattern

Opposite of AllowHosts, AllowUsers, and AllowGroups. Defines a set of hosts, users, or primary groups that are not allowed to connect or login. Wildcards are allowed. All other hosts or users will be allowed access.

X11Forwarding yes|no (yes)

One of the nicer features of ssh is its automatic forwarding of X11 sessions over the encrypted channel. This option allows that forwarding to be disabled.

AllowTCPForwarding yes|no (yes)

If set to "no," disables all arbitrary TCP port forwarding over the encrypted channel.

IgnoreRhosts yes|no (no)

Disables the use of user's .rhosts or .shosts files for authentication. /etc/hosts.equiv and /etc/shosts.equiv are still usable.

PermitRootLogin yes|no|nopwd (yes)

Specifies whether root can login via ssh. Nopwd disables using password authentication for root logins, but other forms of authentication are still allowed.

Note: If using RSA authentication and a "command" option has been set it will be honored regardless of this option's value. This is useful for performing backups without giving direct root login.

PrintMotd yes|no (yes)

Tells sshd to print the contents of /etc/motd at login. This is often taken care of by the login shell and can result in the motd file being printed twice.

RhostsAuthentication yes|no (no)
RhostsRSAAuthentication yes|no (yes)
RSAAuthentication yes|no (yes)
KerberosAuthentication yes|no (yes)
TISAuthentication yes|no (no)

Specifies which types of user authentication are permitted.

Note: RhostsAuthentication is disabled at compile time by default. Kerberos and TIS require compile time configuration.

StrictModes yes|no (yes)

By default sshd checks the permissions of the user's home directory, .ssh directory, and any authentication files before accepting login. This is for novice users who sometimes accidentally leave their directory or files world or group writable.

SyslogFacility DAEMON | USER | AUTH | LOCAL[0-7] (DAEMON)

Tells sshd which facility code to use when logging messages.

Umask numeric-value (no umask set)

Sets the default umask for sshd and all its children.

Client configuration: Command line options for ssh
As with sshd, many of the client command line options are duplicated in the configuration file. The options underlined are also available within the configuration file. Not all available options are explained here. See the man page for complete information.

-f

-n

Tells ssh to background itself after (before for -n) user authentication is done. Stdin is redirected from /dev/null. This is useful for scripts or starting X11 programs on remote hosts.

-l login_name

Specifies the name to log in as on the remote host.

-o option

This option allows the user to specify options in configuration file format on the command line. It provides access to options that do not have a corresponding command line flag.

-p port

Specifies the port to connect to on the remote host.

-t

Force pseudo-tty allocation. This is needed when executing some screen-based programs, such as those that are curses-based or menued.

-L local_port:host:host_port

-R server_port:host:host_port

Specifies local and remote TCP port forwarding over the established channel. This is explained in the first part of this article.

-v

Verbose mode. Causes ssh to display debugging messages about the connection. Extremely useful for debugging connection or authentication problems. Probably the most useful of the command line options and one every user should be made aware of.

-V

Prints version information and exits.

Configuration file settings for ssh
The configuration files for the client programs are located in two places. The systemwide configuration file is located in /etc/ssh_config. The user's configuration file is located in $HOME/.ssh/config. The options here are case insensitive keyword-value pairs -- the same as in the server's configuration file.

Note: It's important to remember the order that options are processed. Of the following sources, the first obtained value in this sequence will be used: command line, user's configuration file, system configuration file.

Host pattern

This option restricts all of the following options to host's matching pattern, until the next Host keyword. The hostname on the command line isn't resolved or expanded until after any matching against pattern occurs. Thus it is possible to set up classes of hosts that are treated separately based on domain name, but only if the domain name is entered on the command line when ssh is invoked.

Hostname hostname

This option allows for the full specification of a hostname, enabling the creation simple host aliases with the Host and Hostname combination.

User username

Specifies the userid to login in as on the remote system.

Cipher idea | 3des | blowfish (IDEA)

This option controls which cipher will be used to encrypt the data stream.

Compression yes|no (no)

This option controls turning compression on and off. Compression has been shown to only be useful when going over slow links, such as dialup or ISDN. Its use over a LAN isn't recommended.

FallBackToRsh yes|no (yes)

Determines if ssh will invoke rsh on the user's behalf in the case that no ssh server was available on the remote host.

ForwardX11 yes|no (yes)

Tells ssh whether or not to forward X11 over the secure channel.

LocalForward port host:port
RemoteForward port host:port

These options are the same as the -L and -R command line options. They allow for automatically forwarding TCP ports over the secure channel. See last month's column on ssh for an explanation of port forwarding.

RhostsAuthentication yes|no
RhostsRSAAuthentication yes|no
RSAAuthentication yes|no
PasswordAuthentication yes|no
KerberosAuthentication yes|no
TISAuthentication yes|no

These specify which authentication methods to try when connecting to the server.

StrictHostKeyChecking yes|no|ask (ask)

When ssh connects to a remote host, it compares the public key sent by the remote host with its local copy of the key (if it has one). In the case where the key doesn't have a local copy, the client can either add the key to the local set of keys and finish the connection, drop the connection without storing the key, or ask the user what to do, respectively.

Additional security options
Ssh has some additional features that make using it for remote administration even more secure. One of the nicest security features of ssh is the ability to control the functionality that a particular key has when logging in. (This feature requires using RSA Authentication.) This is controlled via options in the $HOME/.ssh/authorized_keys file.

The format for the authorized_keys file is a simple one. Each line of the file contains one key. Lines beginning with # or that are blank are ignored as comments. Each key has multiple space separated fields. The fields, in order, are options, bits, exponent, modulus, and comment, with the options field being optional. The comment field isn't really used for anything other than to help identify the key to the user.

Options for a key are comma separated, no spaces are allowed unless they are within a double quoted string. The following are some of the available options:

from="pattern,..."

Limits login by this key to remote hosts where the canonical name matches one of the comma separated patterns (* and ? are available wildcards). Patterns can be negated by prefixing them with a !. Keys are refused from hosts that match a negated pattern.

command="command"

This option is used to restrict access by this key to a single command. And command specified from the client is ignored. This is extremely useful for doing remote administration without giving a full login session.

no-agent-forwarding
no-port-forwarding
no-X11-forwarding

These options prevent authentication agent, X11, or TCP port forwarding when this key is used. Any requests to do the restricted type of forwarding will return an error. These are often used in conjunction with the command option.

TCP wrappers
Wietse Venema's tcp_wrappers package (see Resources below for link) provides additional security features that ssh can take advantage of. If ssh is compiled with the wrappers, you can control the basic ssh connections, X11 forwardings, and TCP port forwardings from the /etc/hosts.allow or /etc/hosts.deny files that also control other "wrapped" applications.

The keywords to use in the allow and deny files are: sshdfwd-X11, sshdfwd-<portname>, or sshdfwd-<portnumber>. If the port being forwarded has an entry in the /etc/services file, the name of the service must be used. Otherwise, the port number will be used.

The server controls access to any remote forwarded ports (using -R or RemoteForward option), while the client controls access to any local forwarded ports (using -L or LocalForward). If a host tries to connect to a forwarded port the host is checked against the entries in the /etc/hosts.allow and /etc/hosts.deny files, and access is determined accordingly.

Closing
Ssh is a powerful tool that can assist you in improving your security framework. Its improved user authentication and end-to-end encryption remove many of the threats to network-connected systems. Even previously insecure tcp-based protocols can now be secured by forwarding them over the secure ssh channel.

When using ssh, a connection policy should be established. It needs to cover port forwarding, X11 forwarding, and root access, at a minimum. The system configuration files for the server and clients need to be carefully evaluated to ensure compliance with the aforementioned connection policy. For systems that need tight security, alternate connection methods, such as telnet or rsh, should be disabled.

The Bookstore: Thinking like a hacker

The book Secrets of a Super Hacker by The Knightmare is the best book on the subject written by a hacker that I've read (although I certainly haven't read them all). (I used the word "hacker" in this review rather than the more correct "cracker" because the book uses this terminology.) First, it's reasonably well written. It doesn't try to be an encyclopedia of bugs or hacking tools. Rather, it's useful because it addresses hacking methods and information that can be used by hackers.

The table of contents includes chapters on the basics, the history of hacking, researching the hack, passwords and access control, social engineering, reverse social engineering, public access computers and terminals, on-site hacking, hacking at home, electronic BBSs, borderline hacking, what to do when inside, computer laws, and avoiding getting caught.

The benefit of a book such as this is that it shows the results of security theory meeting realworld break-in attempts. Quite a few words are spent on gathering information on the target systems, for instance. Knightmare indicates that public information, published security policy documents, audit reports, and dumpster diving are real sources of valuable information. A security audit, if read soon enough by a hacker, can reveal current holes. Even an old audit can be of use, however, indicating what holes were filled. The hacker can then determine the tools used to fill the holes and can pursue specific attacks against those tools. This information reinforces my conviction that although "security through obscurity" is not a sufficient security tool, it is a valuable layer of defense in a site security plan. Just as "the club" does not make a car theft-proof, hiding information about security at your facility doesn't make your systems hack-proof. "The club" does serve to deter crime by encouraging a car thief to steal a car less well protected. Security through obscurity decreases the possibility of hackers discovering your facilities and gaining information necessary to penetrate them.

At times the book is political and obsessive. For instance, there's a diatribe against the U.S. Internal Revenue Service in the section on hacker motivation. Even this is insightful, though. It serves as a reminder that hackers are not necessarily driven by logic or greed. They can hack for revenge, or out of a sense of moral purpose as well. You need to consider the outsider's view of your company or organization, and determine how much motivation a hacker would have to attack your facility. The book also reveals, justly I feel, the bad rap that hackers have but don't deserve. It talks about the bad hackers that are malicious and destructive. But it also points out episodes such as the Secret Service "Operation Sundevil" in which 42 computers were seized, often for inappropriate reasons.

Some of the information in the book is outdated or incorrect, especially in the latter chapters. For instance, there's a lot of information about BBSs, but nothing about Web sites (probably due to the 1994 publication date of the book). Much of the book is surprisingly pertinent and useful today, however.

Unfortunately, the book, with its many break-in anecdotes, some of them astounding, does take a helping-the-hacker tone that might make those trying to keep hackers out uncomfortable (just think of them as cautionary tales). Also, it lacks an index, which makes it difficult to use as a reference work. There are, however, some useful appendices containing lists of known demo accounts for various system types and typical novice and technical passwords. Overall, Secrets of a Super Hacker is an interesting, useful, and perceptive romp through the motivations, tactics, and activities of hackers.

As a side note, the publisher of the book, Loompanics, has produced quite a catalog of, well, offbeat books. Check out its Web site (see Resources) for publications on work, revenge, privacy, locks and lock-picking, torture and death, and of course sex, drugs, rock & roll, among other topics.

The Buglist
CERT has released CERT* Summary CS-98.01 - SPECIAL EDITION that reports on a common bug being used to by crackers to gain root access over networks. The report is about exploitation of a bug in statd on a variety of Unix systems (including Solaris 2.5.1 and younger). Crackers are using tools to automatically test systems for the vulnerability. There is also a new, nasty twist to their methods. In some instances, after crackers get root access to a machine, they install a bogus version of the patch that is supposed to fix the problem. Unsuspecting systems people will check the installed patch list, see the patch number, and assume there is no vulnerability. Meanwhile, of course, the hole still exists. CERT advises that you verify that the patch was installed by someone known to you. The CERT summary is also worth reading for the information on detecting a break-in and recovering from it. The information is not overly detailed but serves as a good refresher.

Patches
Some good news on the patch front. There are two useful tools available for patch management. Casper Dik has created the fastpatch Perl script that automatically removes outdated patch backout information.

Joe Shamblin has created PatchReport that generates a list of recommended, download, checksum, and install patches needed on a given system. As always, you should take care when using security tools downloaded from the Internet.

Correction: We received a correction from someone who wishes to remain anonymous. Apparently, the commercial version of ssh does have support for IDEA, provided that the customer has a valid IDEA license. As a general principle, the commercial version supports everything the free version does, plus additional features. For instance, U.S. readers may be interested to know that an RSA license is included with the commercial version. Thanks for the update.

Resources

• "Enter the secure shell, part one," February 1998 Security column in SunWorld
  http://www.sun.com/sunworldonline/swol-02-1998/swol-02-security.html
• ssh ftp site
  ftp://ftp.cs.hut.fi/pub/ssh
• For more information on SecurID
  http://www.securitydynamics.com/
• TIS firewall toolkit
  http://www.tis.com
• Kerberos FAQ
  http://www.ov.com/misc/krb-faq.html
• tcp_wrapper library
  ftp://ftp.win.tue.nl/pub/security/index.html
• For more information on and to get a copy of rsaref
  ftp://ftp.rsa.com/rsaref
• Wietse Venema's tcp_wrappers package
  ftp://ftp.win.tue.nl/pub/security/tcp_wrappers_7.6.tar.gz
• Secrets of a Super Hacker, by The Knightmare, Loompanics Unlimited
  http://www.amazon.com/exec/obidos/ISBN=1559501065/sunworldonlineA
• Loompanics Unlimited
  http://www.loompanics.com
• CERT* Summary CS-98.01 - SPECIAL EDITION
  ftp://ftp.cert.org/pub/cert_summaries/CS-98.01
• Casper Dik's fastpatch
  ftp://ftp.wins.uva.nl/pub/comp/solaris/auto-install
• Joe Shamblin's PatchReport
  ftp://x86.cs.duke.edu/pub/PatchReport/

• Datafellows (commercial version)
  http://www.Datafellows.com
• Windows 95/NT
  http://guardian.htu.tuwien.ac.at/therapy/ssh
• Another Windows 95/NT
  http://public.srce.hr/~cigaly/ssh
• OS/2
  ftp://ftp.cs.hut.fi/pub/ssh/os2
• PalmPilot
  http://www.isaac.cs.berkeley.edu/pilot
• Amiga
  http://www.lysator.liu.se/~lilja/amigassh
• Or try Aminet
  http://www.aminet.org

• ssh home page
  http://www.cs.hut.fi/ssh
• ssh FAQ
  http://www.faqs.org/faqs/computer-security/ssh-faq/index.html
• Kimmo Suominen's ssh tutorial
  http://www.tac.nyc.ny.us/~kim/ssh
• The best ssh newsgroup is comp.security.ssh
  To subscribe, send subscribe ssh in the body of a message to majordomo@clinet.fi

• CERT ssh security advisory
  ftp://info.cert.org/pub/cert_advisories/CA-98.03.ssh-agent
• CERT Apache security advisory
  ftp://ftp.cert.org/pub/cert_bulletins/VB-98.02.apache
• SunSolve's public patch page
  http://sunsolve.sun.com/sunsolve/pubpatches/patches.html

• Full listing of Security columns in SunWorld
  http://www.sun.com/sunworldonline/common/swol-backissues-columns.html#security
• Related network security stories in SunWorld's Site Index
  http://www.sun.com/sunworldonline/common/swol-siteindex.html#netsec
• Peter Galvin's Solaris Security FAQ
  http://www.sun.com/sunworldonline/common/security-faq.html

About the author
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.

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-03-1998/swol-03-security.html
Last modified: