The VPN Expert: Using Secure Shell with wireless PDAs

Upper-layer tunneling protocols like SSL and Secure Shell allow for narrow access down to individual hosts and ports.

Read about Lisa
by Lisa Phifer, Core Competence

This column is the fourth in a series on securing enterprise network access by PDAs. Previous columns considered...

IPsec clients for PDAs connected to wireless LANs and WANs. These clients create tunnels to secure all IP between the PDA and target network. What if you need to permit just a few specific transactions? Many PDA clients do not support granular IPsec selectors that might otherwise narrow access down to individual hosts and ports. But upper-layer tunneling protocols like SSL and Secure Shell were designed for this.

SSL, WTLS, and the WAP gap
Everyone that has surfed the web has used the Secure Sockets Layer (SSL), a Netscape protocol for securing HTTP transactions. SSL and its IETF-standard successor, Transport Layer Security (TLS), let clients authenticate servers with certificates. Thereafter, application data between client and server is tunneled over an encrypted TCP session -- for example, HTTP carried by SSL to port 443.

Those using SSL to protect wireline access to web applications can support wireless by adding WTLS, a variation created to accommodate latency over slow wireless services. Typically, WTLS between a smart phone and wireless WAN gateway is converted to SSL between the gateway and the target web server. These Wireless Application Protocol (WAP) gateways convert content as well, catering to 4-line smart phone screens and reducing wireless bandwidth demands.

Content-specific conversion and security concerns over the "WAP gap" -- the point of conversion between WTLS and SSL -- make this better-suited for delivering public Web services on a large scale. Those seeking end-to-end security for off-the-shelf non-Web applications may want to consider other solutions.

Secure Shell
One alternative that can be used quickly on a small scale with limited up-front investment is Secure Shell. Secure Shell supports authenticated, encrypted connections between TCP-based clients and servers. Version 1 (SSH1) was invented as a secure replacement for *NIX rsh, rlogin, and rcp commands. Version 1.5 leveraged a technique called "port forwarding" to secure any application that rides over a single TCP session. Version 2 (SSH2) expanded public key authentication options, added Diffie-Hellman key exchange, and offers true message integrity.

Secure Shell's inventor, Tatu Ylonen, made SSH1 freely available as open source. Today, SSH 1.5 is implemented in shareware for many platforms -- including PDAs. SSH2 is more commercialized; client/server products are sold by vendors like SSH Communications, VanDyke, and F-Secure. For the *NIX world, SSH2 is available from the OpenSSH project. Earlier versions of OpenSSH have been ported to WinCE, so SSH2 PDA clients seem likely in the future.

Anytime-anywhere administration from your PDA Due to its origins, Secure Shell is most often used for secure administration -- specifically, to encrypt Telnet sessions to device CLIs. A harried network admin, paged while out of the office, may Telnet to a misbehaving web server or router to fix a problem. Unfortunately, doing so can transmit a privileged login and password in cleartext over the Internet -- or worse, over wireless. These "keys to the kingdom" must be safeguarded; that's where Secure Shell comes in.

Most *NIX servers and many network devices incorporate support for rlogin or Telnet over Secure Shell. Third-party secure Shell servers can also be added to other platforms. To administer any of these servers, you'll need a Secure Shell-enabled Telnet client. Here are a few available for PDA platforms:

Ian Goldberg's TopGun is shareware; the rest of these clients are commercial. But a single Secure Shell client doesn't require a big investment. For example, mov Software's sshCE runs $79 per copy. Most of these PDA clients support only SSH 1.5 with encrypted password authentication and encrypted Telnet. The clients for Symbian and RIM also support SSH2. Some clients, like TopGun, can interoperate with a server running both SSH1 and SSH2 by negotiating down to a common version. (SSH1 and SSH2 are not interoperable.)

I tried TopGun and Mocha Pocket on my Palm m505 over GoAmerica's CDPD. By selectively allowing a TCP port through my firewall to each SSH server, I had no trouble logging into RedHat servers running OpenSSH and several network devices with SSH 1.5. Neither of these clients could connect to my Win32 servers running SSH2.

Punching holes through your firewall can be dangerous. Opening a single port to server delegates security responsibility for that port to that server. It is therefore essential that the Secure Shell server authenticate users, log access, and be hardened to avoid compromise. For example, use public key authentication instead of encrypted passwords whenever possible.

To further reduce risk, my firewall allowed Secure Shell from just one source: the IP assigned to my Palm over CDPD. Static IPs are not always an option, but try to create the most narrow portal possible, and then secure that portal as tightly as you can. This caution applies not just to Secure Shell, but to any tunneling protocol that passes through a firewall.

Even the most secure channel isn't helpful if the end result is unusable. TCP over a slow connection can be cranky. But administrative transactions over Telnet tend to be brief and interactive. I found that I could query and modify device parameters quite productively. Over CDPD, some patience was required. Naturally, MochaCE on a Pocket PC over 802.11b wireless LAN was much easier to use.

Overall, I found ease of use hampered more by tiny PDA screens and data entry limitations than by the wireless network. These Telnet clients offer function keys to speed entry of common strings; this gets easier with practice. The bottom line: I would rather have a secure admin option like this than be helpless when problems crop up while I'm on the road, without laptop or landline access.

Tunneling apps from your PDA with port forwarding
Somewhere along the line, Secure Shell morphed into a general tunneling protocol for TCP. Tunneling is accomplished by "forwarding" a TCP port from the Secure Shell server to another destination.

The client and server authenticate each other, setting up a Secure Shell session between them (by default, port 22). The client then asks the server to relay single TCP ports in either direction. For example, the client might ask the server to forward locahost:110 (POP) and 25 (SMTP) to and 25. Thereafter, when Eudora, Outlook, or your favorite mail client sends and receives mail to/from localhost, mail is encrypted between the client and Secure Shell server. At the Secure Shell server, mail is relayed as cleartext to This protects traffic on public links. When a Secure Shell server forwards ports, it is acting as a security gateway.

Port forwarding can be a quick, inexpensive way to set up a security gateway for one or two applications -- Telnet, SMTP, and POP to an OpenSSH server illustrate this. However, Secure Shell does not forward UDP or ranges of TCP ports. Helper applications can forward some UDP protocols; it is possible to create forwarding rules for each port/destination. If you need broad tunneling, consider a network layer VPN instead. If you just want to secure a few ports, look at Secure Shell forwarding.

Unfortunately, port forwarding options for PDAs are quite limited. As explained in Top Gun release notes, "Seeing as how PalmOS doesn't support daemon processes running in the background, you couldn't have both TGssh and, say, a mail client running at the same time." I found just one Secure Shell utility capable of forwarding: a WinCE shareware port of Portable OpenSSH 1.2.3 called PortForwarder, developed by Fujio Nobori.

Configuring PortForwarder can be a little tricky; read the online "How To Use Port Forwarder"instructions and start with the sample config there. It took me about an hour to get things just right on my Pocket PC. I forwarded Telnet to several managed devices, HTTP to several Intranet servers, and POP/SMTP to my ISP's mail servers, all over a single Secure Shell tunnel:

  • For device administration, forwarding Telnet over a single tunnel can be easier to control and track than punching separate firewall holes to each device.
  • Forwarding HTTP to individual servers is simple. But Secure Shell is not a solution for securely accessing any arbitrary web server. For example, you cannot follow offsite links to external servers with port forwarding.
  • My POP, SMTP, and IMAP port forwards provide confidentiality over wireless. However, the "last mile" relay from my Secure Shell server to my ISP's mail server carries cleartext over a private link that I (must) trust.

Forwarding FTP is possible, but as not straightforward, because FTP uses control and data sessions. Newer SSH2 servers support SFTP, a Secure Shell standard for file transfer without separate FTP sessions. I am not aware of any PDA client that supports SFTP, but expect to see it surface in SSH2 PDA clients at some point.

Protecting wireless PDA transactions with Secure Shell can be useful, but is not for everyone. Secure Shell can save time if you don't have a remote access VPN solution already in place. System and network administrators seeking PDA CLI access over wireless will find Secure Shell a much safer alternative than Telnet alone. Admins with Pocket PCs will find PortForwarder a useful complement. Tech-savvy users with no budget can leverage PortForwarder to tunnel other single-port transactions over wireless. Larger companies and novice users are likely to look elsewhere until more fully-featured Secure Shell clients become available on more PDA platforms.

Do you have comments about this article, or suggestions for Lisa to write about in future columns? Let us know!

This was first published in May 2002
This Content Component encountered an error



Find more PRO+ content and other member only offers, here.



Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: