To enable end-user access to hosts in the Linux/UNIX environment, the old standbys have been telnet (for shell access) and FTP (to transfer files). These protocols have been around since the mid-1980s, and are defined by RFC 854 [rfc-archive.org] (telnet) and RFC 959 [rfc-archive.org] (FTP).

They're also very insecure. Both protocols conduct their communication “in the clear”, meaning that not only are the login credentials sent unencrypted, but all of the data sent back and forth are likewise open for anyone to read. Every keystroke, every password, every byte, can be silently intercepted and/or recorded.

Even within a “closed” or heavily-firewalled network, it is easy to overlook the dangers of unauthorized ARP- or ICMP-based re-direction, which would allow someone who had gained access to the network (legitmately or not) to conduct “man in the middle” (MitM) or similar attacks. Telnet and FTP offer no defenses against this, or any way to detect such subtle intrusions.

The original Internet environment was populated by a relative few, and relied as much on trust as anything else. More than 20 years have passed since then - the modern computing environment, for better or worse, is not inherently trustworthy, and insecure tools can be as dangerous as they are ubiquitous. Telnet and FTP are both. New, secure tools are needed.

...OpenSSH and rssh?

The Secure Shell protocol is actually a series of protocols, defined by several RFCs, including:

• RFC 4251 [rfc-archive.org] Secure Shell (SSH) Protocol Architecture
• RFC 4252 [rfc-archive.org] Secure Shell (SSH) Authentication Protocol
• RFC 4256 [rfc-archive.org] Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)

OpenSSH [openssh.org] is probably the best-known implementation of the SSH suite, and arguably the one with the widest OS vendor adoption, being supported on platforms as diverse as IBM AIX, Novell NetWare, Sun Solaris and practically every Linux distribution.

Important!

The specifics of support for platforms vary by the platform. For example, the QNX implementation doesn't support post-authentication PrivSep (the PrivSep feature is described later in this paper). While NetWare has included OpenSSH for years, the NetWare console environment is not analogous to the *NIX terminal/shell environment; hence, rssh can't really function on the NetWare/OES-NetWare platform (thus, with regards to Novell's products, this paper is really only applicable to NetWare's successor, Open Enterprise Server, specifically OES-Linux; and SLES).

OpenSSH combines the shell/command-line functionality of telnet with the file transfer capability of FTP. Through its subsystem feature, its functionality can be extended even further. Using a single software stack for these services simplifies system management, providing a single point for configuration, authentication and logging.

Important!

This paper is based on the Portable version of OpenSSH, which varies in a number of ways, subtle and otherwise, from the OpenBSD version of the package. If you are using the OpenBSD version and encounter documentation conflicts between this paper and the man pages, consider the OpenBSD man pages as the more accurate source for that platform.

rssh [pizzashack.org] is an extension to the OpenSSH environment that allows the system administrator to more finely control access through OpenSSH. Designed to work specifically with OpenSSH, rssh is a restricted shell that can prevent or allow specific functions of OpenSSH, on a global or per-user basis.

...not “secure” telnet or FTP/S?

When considering implementation of telnet and FTP protocol variations that provide secure communications, the first thing one must ask is: “Which one?”

For example, just for FTP, there are at least two RFCs for providing “secure” FTP:

• RFC 2228 [rfc-archive.org] FTP Security Extensions
• RFC 4217 [rfc-archive.org] Securing FTP with TLS

Similarly, several RFCs cover options to “secure” telnet; among them:

• RFC 2946 [rfc-archive.org] Telnet Data Encryption Options
• RFC 3205 [rfc-archive.org] On the use of HTTP as a Substrate

None of these methods enjoys wide implementation or vendor acceptance. Further, this approach results in two software stacks for what are really very similar purposes, whereas OpenSSH is a single software stack for both activities. With the submission of RFCs for the SSH protocol, OpenSSH becomes just as “standard” as telnet and FTP have been.

...this paper?

The goal of this paper is to provide a basic roadmap for the installation and configuration of OpenSSH and rssh in a *NIX/Linux environment. Then, the paper will cover how this software combination can be leveraged to provide a secure communications framework. While functions, such as port forwarding and the ability to tunnel other protocols through SSH, are mentioned, those topics are outside the formal scope of this paper. Similarly, integrating OpenSSH with specific authentication back-ends (such as Kerberos) or additional security tools (such as TCP Wrappers) are also outside the scope.

It is important to keep in mind that these tools are not a magic security bullet. They will not protect against an account compromised by other means (e.g. someone learning a user's password, perhaps by social engineering), filesystem insecurity, attacks against other services (e.g. a webserver exploit) or insecure configuration of other tools or services.

OpenSSH [openssh.org] and rssh [pizzashack.org] are both Free/Open-Source Software (FOSS) packages. These softwares are among those that I prefer to build from source, so this paper covers those steps.

Common practice in the Linux/UNIX world is to install pre-built packages, usually provided by the platform vendor or distribution maintainer, rather than to build from source. Where a package is not part of the “official” offering, it is often available from a 3rd party (e.g. the package author, a site like SunFreeware [sunfreeware.com], or other independent repository). Many modern Linux/UNIX distributions include a pre-built OpenSSH. rssh is also available in package format, although it seems less common to find it already included in distributions (some versions of Gentoo and Debian have it).

Why, then, does this paper take the build from source approach?

When using a pre-built package, one must accept whatever compile-time configuration decisions were made by the package creator. These parameters may or may not be adjustable at run-time, and compile-time options selected by the package creator may or may not be appropriate to a specific environment. Building from source allows tailoring the software. As with any other system administration decision, weigh the factors in the environment and choose a course of action.

If you decide to use a pre-built package, skip past the Compilation and Installation sections - start reading at the Configuration section. You should follow the package installation documentation, and reference this paper for configuration tips. The current versions, as of this writing, are OpenSSH v4.7p1 and rssh v2.3.2.

This paper's assumptions, for those wishing to build from source, include the use of a modern Linux or UNIX (or UNIX-like) operating system, the ability to run shell scripts, compile C code (with GNU gcc or an equivalent), copy and/or link files, and set file modes and ownership. While some of these tasks require root privilege, you should only invoke that when you specifically need it (for example, most compilation steps can probably be accomplished as an unprivileged user). Additionally, this paper assumes that OpenSSL, and the zlib compression libraries, have already been installed and configured.

Every system admin has their own way of doing things, and their own sense of where to put files. This paper is written from my perspective on these issues, which may be different from the maintainers of the pre-built packages. Select whatever file location scheme for these tools that is appropriate to your environment, and if necessary translate my paths and locations into the scheme you select.

My personal environment is usually either SLES v9 (or later) with gcc v3.3.3 (or later), RHEL v4 (or later) with gcc v3.4.6, or Sun Solaris v8 (or later) with gcc v3.3.2 (or later). Other common tools include GNU make v3.8x and nano v2.0.x; however, I try to use a platform's stock development tools such as ld, ar, yacc and lex. I tend to create a sub-directory structure specifically for building add-on tools, generally /work. Make sure the partition where this is located has adequate room.

I usually install add-on tools, like OpenSSH and rssh, in a sub-directory off of /opt, and then use symbolic links in /usr/bin or wherever else might be needed. This allows me to control access better than if everything is dumped in /usr/local. I prefer symbolic links because I frequently make /opt its own partition, and I can “snap-in” a newer version of a tool with a few mv commands, since the link is merely a pointer to a path and file name (a hard link points to the inode entry and can't cross partition boundaries).

Administrators accustomed to working in a homogenous environment may wonder why this paper does not mention or advocate the use of specific tools for deployment beyond a single machine, or uses techniques that might seem problematic when viewed from a specific environment perspective. A reader might find themselves thinking “Why not just use <insert tool name here>?” or “That suggestion doesn't make sense in <insert specific environment name here>!!”

This paper is deliberately written for a generic audience, where a reader may be interested in applying the information presented in diverse environments, perhaps other than a typical Linux distribution or common UNIX variant. As a consequence, it offers ideas culled from a number of environments. The reader is encouraged to consider those ideas, techniques and tools that are applicable to their situation, and to ignore those that are not.

OpenSSH can be compiled with support for TCP Wrappers [porcupine.org], although doing so is not specifically covered in this paper. If TCP Wrappers is installed on the system but you decide to not compile OpenSSH with TCP Wrappers support, you can still leverage TCP Wrappers by invoking sshd via inetd (or xinetd). Consult the TCP Wrappers documentation for details.

Note to Solaris Admins: As of Solaris v9, Sun has been adding TCP Wrappers support to Solaris. The package name is SUNWtcpd.

Note to Linux Admins: Virtually every Linux distribution includes the OpenSSH package, and practically all of them link OpenSSH against TCP Wrappers. If you choose to compile your own OpenSSH (perhaps to get a newer version than the distribution maintainer provides), then linking against TCP Wrappers is recommended.

However might be appropriate for your environment, download the latest OpenSSH and rssh source packages. I download mine into /work/openssh and /work/rssh, respectively:

If your tar program includes the ability to decompress gzip-ed files, then you can use it directly; or you can call gzip as a separate step on the way to un-taring the files. Here, I'm showing the latter method, and writing three commands separated by semi-colons:

...and...

The commands will decompress the files, unpack the tarfile, then recompress the tarfile using the best compression offered by gzip. No sense wasting disk space leaving the uncompressed tarfile around. Or you can delete the tarfile. If you like and have it installed, substitute bzip2 [bzip.org] for gzip when re-compressing - the results tend to be better.

The source files now reside in a directory named very similar to the file from which everything was extracted. If you, like me, use the autocompletion capability of your shell, this can be annoying. So I usually change the directory name to something short:

Now autocompletion won't beep at me. I can get ready to build OpenSSH with: