Secure Remote Sessions

Francisco M. De La Vega

During the design and implementation of a corporate information infrastructure, special consideration is usually given to the security aspects of the architecture. Strategies ranging from encryption to firewalls are commonly discussed. Firewalls can provide a strong barrier and isolation against external attacks and unauthorized access to the corporate information assets. However, this protection is gained at the cost of reducing the services crossing the corporate frontier. But, what happens when corporate users need to access company information and services from the Internet? The current trend in user mobility and extranet access to enterprise networks by business partners poses a difficult security problem.

Often the asset requiring access is a very simple but important one: corporate email. Field engineers, salespersons, and executive personnel need to access internal servers and applications when they are away or just at home. System administrators often need to take emergency actions when their pagers signal important system events, or just to check if everything is in order before being able to sleep. Some companies have provided modem access directly to their internal network for these key personnel. This is costly and sometimes not secure. The drive behind the creation of Virtual Private Networks (VPN) using the public Internet infrastructure as part of the corporate WAN is to reduce costs. It is much more cost-effective to provide employees and partners with a dial-up account to a local ISP than to provide dedicated access.

Some of the problems of remotely accessing corporate information can be alleviated using properly secured Web interface systems (see "Securing Intranets" in the June, 1997 issue of Sys Admin). But, in this article, I focus on the issue of securing interactive remote sessions connecting to internal servers.

Remote Access Problems

The security problems for allowing external sessions to corporate servers can be separated into two aspects: user authentication and privacy. It is essential to unambiguously authenticate all connection attempts before allowing system access. The classic TCP/IP tool for this task, namely telnet, does not provide the required level of security to authenticate users and avoid impersonation by crackers who have gained password information. It is widely known, for example, that telnet sends passwords in plaintext across the network.

Despite the press coverage of more sophisticated attacks, the number one cause of system intrusions is still password sniffing. It is relatively easy for a cracker to install a packet sniffer at some point along the path between clients and servers (your partner network, your local ISP network, that nearby PC where a sysadmin-wanna-be is playing with Linux, and so forth). Once one server is compromised in a network, all the servers are compromised, and often servers in associate companies are, as well. This is the result of the fact that passwords are reusable and that trust relationships exist between servers. Thus, a possible strategy to reduce masquerading risk and to enhance user authentication for remote access is to use a one-time password system.

Solutions for Secure Remote Access

There are several single-use password authentication systems around, but most of them are related to the S/KEY application developed at Bellcore1. Versions of S/KEY can be obtained for free, and several commercial applications are compatible with S/KEY. S/KEY uses a challenge/response mechanism, whereby a shared secret exists between the user and the server: a password or passphrase. However, the password is never sent through the network. When a user attempts connection, a key computed through a one-way function from the shared secret is presented to the user. The user uses this key as input together with the secret password. The S/KEY password generator program then produces an access password usually made of four or five unrelated words (so that they can be memorized if obtained in advance). This password grants access to the system only for this time. Next time another key is generated for that user, and a new password is used. A typical setup would install the S/KEY server in the firewall machine. Thus, users have access to the firewall connection services only upon authentication. A connection can be subsequently started from the firewall to an internal server where the user finally logs on.

There are S/KEY applications for almost any platform, including PDAs. But what happens when the mobile user does not bring his/her own computers? A variation of the idea is the portable password generator cards (e.g., SecureID). These cards produce different passwords every minute or so, are very portable, and have a small window where the currently valid password for the card holder is displayed. Cards are cheap enough for medium to big corporations to afford them. Cards can be stolen or lost, and distribution of the cards can become problematic. These methods normally establish a connection through a standard telnet client after authentication, however, which can still lead to security risks.

The most important disadvantage of the described one-password systems is that they only solve the authentication problem. Once a session is started, all the information is sent in plaintext over the network, and is thus prone to surveillance. Some information typed after the login can be as valuable for a cracker as the user's password itself. For example, the cracker might watch for certain command strings, such as use of the su utility, thereby discovering the root password. Or, the cracker might discover that some users can su to root without a password (there are several utilities that allow this practice for the purpose of simplifying system administration by junior personnel).

Packet sniffing by a cracker can also lead to other types of information leaks, such as discovering the names and IP addressees of other internal systems, or revealing valuable industrial espionage information when a user reads email. Thus, privacy is not addressed with one-time password applications. Furthermore, this strategy does not authenticate the server, and man-in-the-middle attacks are possible.

Maintaining privacy of remote sessions requires an encryption technology that enables a secure channel after proper authentication. Furthermore, since cryptography provides robust methods of user authentication without the need of one-time passwords, a complete scheme for secure remote sessions can rely solely on encryption technology. There are a couple of applications that take advantage of this scheme. Secure RPC Authentication (SRA) for telnet and ftp is a public domain application that uses DES 56-bit encryption to protect a reusable password through a challenge/response method. It requires special clients and server programs (modified telnet) and is available only for UNIX. If can be obtained at: ftp://net.tamu.edu:pub/security/TAMU/ \ srabin-1.1-sparc-solaris.tar.gz. But, its main disadvantage is that after authentication, the rest of the session is not protected. STelnet (secure telnet) and SSLtelnet are two applications that use SSL protocol to provide user authentication through X.509 public-key certificates and subsequent session encryption. SSLtelnet even provides support for S/KEY one-time passwords. Although these applications are attractive, since they rely on an open protocol and Internet standards (SSL and X.509), currently they are only available for UNIX. The typical application of secure remote sessions must also run on PCs and Macintoshes - the common clients that remote users have.

Secure Shell

An application for encrypted remote sessions that has gained considerable interest is SSH or Secure Shell. SSH was developed in 1995 in Finland by Tato Ylonen, a computer science professor. Last year SSH development was turned over to the SSH Ltd. team in Finland2, and commercial distribution is done by Data Fellows, Ltd.3, a firm previously known for antiviral software. Data Fellows released Windows and Macintosh commercial clients and some other variations of the basic SSH protocol (F-Secure product line). The UNIX server is still free for non-commercial purposes. SSH gained large popularity when the application was available only for UNIX, accounting for about 5% of backbone Internet traffic in 1996.

SSH allows strong cryptographic authentication through a 1024-bit RSA public-key cryptosystem, and private, encrypted sessions using one of a variety of symmetric-key encryption algorithms, usually IDEA or triple-DES. But most importantly, since SSH was developed in Europe, it is not constrained by the U.S. export restrictions. Thus it can be obtained either free for non-commercial purposes (UNIX version only) or commercial versions where allowed by local legislation, all over the world. The session encryption algorithm can be adjusted according to licensing restrictions; for example IDEA or triple-DES, which by now is legal almost everywhere.

SSH is aimed to replace the notoriously insecure rsh and rlogin commands, and telnet as the choice remote session applications. And since it is now available for all major platforms, it provides a good solution for the corporate remote access problem. But SSH is more than a secure session application; it provides proxying and routing of other TCP/IP applications through the encrypted channel. X11, a notoriously insecure protocol, can be re-routed through a SSH tunnel, as well as POP, a popular protocol to access corporate email, which is insecure because it sends password and information in the clear. SSH includes a secure analog to rcp - a secured ftp application is still in the works.

Authentication in SSH is based on the robust RSA public key cryptography using long keys (1024-bit). The private key should reside in the personal computer of the user, and the public key can be distributed to the servers where access is required (by a manual procedure). Since the file with the private key conceivably can be stolen, it is protected with a long passphrase in a very similar way to PGP. SSH uses as well-known TCP port, port number 22. Thus, firewalls can be easily configured to allow port 22 traffic to a certain server. I normally disable root logins and ftp on all my servers, but SSH is the only service I would think of granting root access directly, at least between specific internal servers for some admin tasks.

Installation and Configuration

SSH distribution for UNIX can be obtained from SSH Home Page4. It needs an ANSI compiler installed, usually gcc, and Perl v. 5.003. SSH compiles just fine on most UNIX platforms, including Solaris, SunOS, and Linux. After unpacking the distribution (current version is 1.2.17), a Makefile is produced after a configuration script is run (config) - this finds out the OS version and peculiarities of the system. Then just a make and make install would finish the basic job. Compilation produces two binaries, sshd and ssh (the server and the client), and some Perl scripts used for configuration.

SSH can be configured to compile with Wietse Venema's TCP wrapper libraries, thus honoring the /etc/hosts.acces and /etc/hosts.deny files. Also, it can replace the system's rsh and rlogin programs, so that any user who tries to use these would be actually using SSH. The installation procedure installs two configuration files in /etc: sshd.conf and ssh.conf - these configure the operation of the sever and client processes, accordingly (see Listing 1 - listings are available from: ftp.mfi.com in /pub/sysadmin). As an extra security measure, SSH creates a RSA public key pair for each server when first installed. These keys are kept in /etc/ssh_host_keys, and although these are not protected by a passphrase, they add some security. SSH daemon should be started as a standalone process either from the command line, or in the startup scripts. sshd is a root suid process, because it needs to bind to port 22 and to gain access to the server's private RSA key. The latter is not strictly required, but is convenient because it provides more security through server authentication.

When a user first runs SSH, a 1024-bit RSA public key pair need to be generated and saved in HOME/ssh/identity (the private key) and $HOME/ssh/identity.pub (the public key). A passphrase to unlock the private key is requested, and a commentary is associated to the keys (e.g., an email address; see Listing 2). The $HOME/.ssh directory and its contents should only be accessible by the owner, otherwise creating a big security hole, and thus SSH will refuse to use RSA authentication. Obviously, the server side of a SSH session should have sshd previously installed and running. Upon first contact with a given server, SSH stores the name and public key of the server in $HOME/.ssh/known_hosts, letting the user know this is a newly known host. For RSA user authentication the public-key of the user should be present in the server at $HOME/.ssh/authorized_keys file. This requires the user to manually append the public RSA key found at $HOME/ssh/identity.pub in the client machine to $HOME/.ssh/authorized_keys file on the server. If the home directory is actually the same physical device in both client and server (e.g., when residing on a NFS server), the contents of identity.pub should be appended to authorized_keys anyway. If the public key is not found, SSH tries to authenticate using the UNIX system password.

This latter authentication method is much less secure, though the password is not sent in the clear as in a simple telnet, but is sent encrypted with a symmetric session-key previously negotiated. If security is at a premium, it is possible to configure RSA authentication as mandatory in the sshd configuration file, /etc/sshd.conf. Once the session is started, all traffic is encrypted with the session key, as can be tested with a sniffer - no passwords or clear packets can be obtained. Session encryption is negotiated with one of several bundled algorithms, including triple-DES, IDEA, Blowfish, and symmetric-RSA. Once properly installed, SSH can effectively substitute telnet and UNIX r-commands for remote sessions, remote shells, and command execution - well-known origins of security problems. In fact, SSH can be configured to honor .rhosts and /etc/hosts.equiv files used in r-commands, or use enhanced .srhosts and /etc/shosts.equiv alternative files. SSH will refuse to use these files if the appropriate file permits are not in place, a common security hole. It is suggested to backup and remove from the path the original r-commands and allow symbolic links to SSH substitute their functionality. You can also block external r-commands connections attempts by eliminating their entries in /etc/inetd.conf, or restricting with TCP wrappers access control lists. In this way, all remote sessions will be carried out by SSH, but in contrast to r-commands, after effective authentication and maintaining session privacy.

After setup, SSH usage is transparent for users, and the administrator may find it useful to use SSH for remote backups through an encrypted channel, or accessing systems under her/his administration after highly confident authentication and su to root without risk of eavesdropping. SSH includes a remote copy tool to transfer files through the encrypted tunnel, although no fully functional secure ftp tool is yet available.

SSH Windows and Macintosh Clients

While SSH can be extremely useful as a remote session tool for UNIX-to-UNIX server communication, my goal was to provide an easy tool for secure remote sessions to diverse corporate users. These users range from mobile personnel, to home access to corporate email, and system resources. Most of the time these users will have either a Windows or Macintosh system locally available. Data Fellows sells Windows and Macintosh SSH clients under the name of F-Secure client. A 30-day trial version can be downloaded from their European Web site4. After uncompressing the distribution file, an installer program will place the appropriate reference files in the system and generate the client's public and private 1024-bit RSA key-pair. Due to limitations in PC's and Mac's clock accuracy, the random seed needed for RSA key generation is obtained from the timing in the users' pointer movements, a very effective randomness source. Thus a window instructing the user to move the pointer will be followed by RSA key-generation; this process may take some time. To enable RSA authentication, the user should generate a personal RSA key-pair, protected by a passphrase (see Figure 1). The private key is normally kept in a file under the name identity at the SSH program folder. The public key can be copied to the clipboard and used to append the $HOME/.ssh/authorized_keys file of the target UNIX server (Figure 2) to enable RSA authentication.

The session is started providing the server's name and selecting between either password or RSA user authentication (Figure 3). A window will prompt the user for the passphrase needed to unlock the private key, completing authentication (Figure 4). SSH will compress all the traffic, thus compensating any delay caused by the encryption/decryption process by optimizing bandwidth usage during dial-up Internet access. Obviously, if a firewall is in place to restrict access to the corporate network from the Internet, connections to port 22 (the well-known TCP port used by SSH) should be allowed to enter the appropriate servers. Authentication type, cipher used for sesion encryption, and compression mode are configured from a simple control panel (Figure 5).

Other SSH Applications

SSH is not only a secure remote sessions tool, it also provides an encrypted channel on top of TCP/IP protocol that can have other uses. Interestingly enough, SSH can route other TCP/IP services through the encrypted channel. Local applications need to be directed to the loopback IP address; SSH intercepts these packets, forwards them through the tunnel, and once in the server side, redirects them appropriately. This can be very useful to protect other TCP/IP applications that do not have security, like the old and unsecure X11 protocol.

In UNIX, SSH sets the $DISPLAY variable to the loopback to allow X11 forwarding. Make sure posterior scripts or commands does not change $DISPLAY, or otherwise X11 will not be forwarded through the tunnel. The program automatically sets $DISPLAY on the server machine, and forwards any X11 connections over the secure channel. Fake Xauthority information is automatically generated and forwarded to the remote machine. The local client automatically examines incoming X11 connections and replaces the fake authorization data with the real data (never telling the remote machine the real information). If the $DISPLAY variable is set on the client side, the server will create a dummy X server and set $DISPLAY accordingly. Any connections to the dummy X server will be forwarded through the secure channel, and will be made to the real X server from the client side.

Arbitrary TCP ports can be forwarded over the secure channel. The program then creates a proxy bound to the designated port on the client side, and whenever a connection is opened to this port, it will be passed over the secure channel, and a connection will be made from the other side to a specified host:port pair. A useful application is to forward POP or SMTP protocols through the SSH channel to access/send email from a remote client. HTTP can also be forwarded, thus allowing a mechanism for Web access to Intranet pages when SSL is not needed or desired. Figure 6 shows the configuration panel of F-Secure client used to forward other protocols through SSH tunnel.

This tunneling capacity of SSH can be used as the basis for a simple Virtual Private Network architecture to encrypt the traffic between small external networks and a central corporate Intranet using UNIX servers (see Arthur Donkers' article in the July issue of Sys Admin). Data Fellows also sells a commercial VPN product based on SSH that allows the implementation of firewall-to-firewall encrypted channels for Windows NT.

Caveats

SSH allows secure remote sessions that provide strong authentication with effective privacy without the need of one-password systems. There are also some disadvantages in SSH. There is an inherent risk in the fact that private RSA keys are stored in magnetic media, sometimes in a shared user environment like UNIX. It is a possibility that a cracker may steal the user's private key. SSH provides some protection against this threat by refusing to use RSA authentication if local files are not appropriately protected, and by the need of a user phassphrase to unlock the private key. These passphrases are usually longer than simple UNIX passwords, and users are more willing to use them since they are more easily memorized. Correct set-up of SSH can be a bit complex for some end users and is not automated or centralized, requiring manual transference of public keys. Reuse of a key poses some risks in the long term, since crackers have more time to try to break it by brute force. However, the major disadvantage in SSH is that it does not support X.509 public-key certificates to distribute and manage RSA keys. This hinders SSH from several management applications and integration to other Intranet applications, such as LDAP directories and certificate servers. Despite these facts, SSH is an effective, simple, and easily deployed tool that can improve the security of a corporate architecture while providing the flexibility of remote access to Intranet's information assets - features most systems administrators would appreciate.

References

1. Pointers to cryptographic software (includes pointers to software described here and much more): http://www.cs.hut.fi/ssh/ \
   crypto/software.html
2. Secure Shell Homepage (for the free UNIX version): http://www.cs.hut.fi/ssh/
3. Secure Shell Ltd. Home Page: http://www.ssh.fi
4. Data Fellows Ltd. Home Page: http://www.datafellows.com