by Joe Goldthwaite, Bar-S Foods
Updated by Peter Schellenbach, Zumasys (2014)

If you’re not using Secure Shell when you access your legacy system over the Internet, your assets are definitely not covered!

The Internet has given us a great deal of flexibility in accessing our host systems from remote locations. Unlike using a modem or serial connection, telnet allows you to connect to multiple machines anywhere in the world at the same time. This hasn’t come without a cost however. Most people don’t understand that telnet was designed at a time when the Internet was small and fairly safe. Today, the Internet is full of hackers who’d love to play on your system and telnet lets them right in! You see, telnet sends all its data as plain text. Crackers with network sniffers can tie into the data stream and see everything you’re doing. All your passwords, account names, etc. are right there. What’s even worse, there are no native ways of securing telnet. Some large companies simply don’t allow any telnet connections into their system for just this reason.

So what’s the solution? Secure Shell! Secure Shell (SSH) is a newer protocol that automatically encrypts the data stream making it illegible to anyone tapping into the stream. SSH was designed as a replacement for telnet. It has the same ease of connection without the security risk. SSH uses public key exchange to secure the connection, then encrypts all session data, including user names and passwords, using a standard encryption algorithm (AES and triple DES are commonly used).

SSH provides strong authentication and secure communications over an insecure channel (the Internet). SSH protects against IP spoofing, IP source routing, DNS spoofing, interception of passwords and other data as it passes through intermediate hosts, and alteration of session data by intermediate hosts.

To use SSH, you need two pieces of software: An SSH server on the host machine, and SSH client software for the remote PC.

Most Unix, Linux, and AIX systems already include the SSH server software. If yours does not, check out, Commercial and open source SSH servers are also available—check out To enable SSH connections to your host, you simply need to start the sshd daemon or ssh server service, just like the telnetd daemon or telnet service.

On the client side, you’ll need a terminal emulator that supports SSH. AccuTerm® 7 and AccuTerm® 2K2 support SSH version 1 and 2 (AccuTerm® 2000 only supports the obsolete SSH version 1). Several other commercial and free SSH clients are also available—check out Establishing a secure connection is as simple as opening a telnet connection: you need to specify the host IP address (or host name), and optionally the SSH port number (22 is the default SSH port). Enter your user name and password, and if the host is able to authenticate your identity, you’re in!

Using SSL/Telnet for Secure Connections

An alternative secure connection protocol was added to AccuTerm® 7 in 2013: SSL/Telnet. This is basically a hybrid protocol: first a secure connection is established from client to host using SSL (Secure Sockets Layer), also known as TLS (Transport Layer Security). This is the same protocol use for secure web browsing (https). Once the secure connection is established, a normal telnet session is “tunneled” through the secure channel.

There are two drawbacks to using SSL/Telnet instead of SSH. First, it is uncommon (and complex) to perform key-based client authentication using this protocol. SSL is designed to provide server authentication using a server SSL certificate, which is the second obstacle—you cannot use SSL without a server certificate (although self-signed certificates are allowed).

On the other hand, SSL/Telnet may be the preferred secure connection protocol for Windows-based MultiValue installations. The free open source utility stunnel ( can be used as a proxy on Windows, accepting SSL connections and forwarding them to the telnet server on the same machine (localhost).

If you’re still using simple telnet to access your legacy systems over the Internet, you’re assets are definitely not covered.

Return to Technical Articles