Cover Your Assets Using Secure Shell

by Joe Goldthwaite, Bar-S Foods

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 (3DES is the default algorithm for SSH1).

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.

Many Unix and Linux systems already include the SSH server software.  If yours does not, check out www.openssh.org, or for RedHat Linux, search the download page at www.redhat.com for “openssh”. To use openssh, you must also download and install openssh-server, openssh-clients and openssl.  Commercial SSH servers are also available (check out www.datafellows.com).  To enable SSH connections to your host, you simply need to start the sshd daemon just like the telnetd daemon.

On the client side, you’ll need a terminal emulator that supports SSH.  AccuTerm 2K2 and AccuTerm 2000 include built-in SSH version 1 support; a free SSH update for AccuTerm 97 is available at www.asent.com.  Several commercial and free emulators with SSH support are also available (SecureCRT, F-Secure, etc.).  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! 

At this time we do not know of any SSH servers for Windows NT or 2000 Multi-Value platforms.  If you are hosting your applications on Windows NT or 2000, you might consider setting up a Linux machine as a gateway between the Internet and the host.  Remote users can connect to the Linux gateway using SSH, then a login script can automatically “telnet” to the NT/2000 host on the internal LAN.