SSH and Telnet

Telnet. Telnet is the standard terminal emulation protocol within TCP/IP. Telnet is defined within RFC 854. Telnet allows a user on a TCP/IP network like the Internet to login to another computer on the network remotely. Of course this can be done only if the user has the appropriate permissions on this remote computer. But Telnet allows a user to access remote resources as if the user had a local connection.

Telnet makes use of port 23.

It should be obvious that it is very important to control access to Telnet on machines and routers when setting them up.

Telnet is actually a relatively old protocol and has very little security. Information is passed across Telnet in the clear. Things that are passed in the clear includes usernames and passwords. So it should be obvious that Telnet is not something to be used in many situations.

The next discussion describes some situations where I have seen Telnet used.

Telnet for Some Group Research - When the Internet first became widely available I was at Rider University south of Princeton, New Jersey. I had a colleague at Clark University up in Wooster Massachusetts that I wanted to do research with. We needed to work on developing some software as well as writing some papers. The software was quite complex and we wanted to use C and/or C++.

My colleague did not have the capability to make use of C/C++ at Clark. We had it on a few PCs at Rider, but these would not be accessible to him. Fortunately, we had a version of VAX C on a VAX supermini at Rider that was on the Internet. I was able to get an account on this supermini that we could both login to. He had to use Telnet. But this allowed us to both work within the same account even though we were a couple hundred miles away from each other.

Telnet for Accessing Administrative Resources - When I was a professor at Quinnipiac University there were a variety of resources available for use by faculty, students and staff. There was a Windows based network that was used for most educational purposes. There was also a UNIX based network that was used for administrative purposes such as registration, keeping track of student records and so on.

Some staff members needed to access both from their computers. The solution that had been implemented at Quinnipiac was to have staff Telnet into the administrative network. This worked somewhat reasonably. But I was quite disturbed to discover their central computing staff did not understand the security vulnerabilities of Telnet at all. At some point we even found sniffing devices tied into wiring under staff member's desks. QU central computing seemed to want to treat all these sorts of things as pretty acceptable risks.

SSH - Secure Shell. SSH - Secure Shell was designed to create much greater security in network functions. It relies on a set of functionalities and protocols that facilitate things such as the following.

secure remote login

provide authentication

secure file transfer

secure forwarding of traffic

TCP/IP

X Window system

encrypt data

compress data in transit

Telnet originated quite early in the development of UNIX. In efforts to overcome the security vulnerabilities of Telnet, SSH was developed.

Efforts to improve on Telnet have included the following.

rlogin - Remote Login

RSH - Remote Shell

RCP commands

SSH has been developed to improve on these.

SSH makes use of both a client and a server that use public key cryptography to provide session encryption. SSH opens a secure transport between machines by making use of an SSH daemon running on each end. One daemon initiates communications using port 22. After this secure communications are carried out over higher numbered ports using appropriate modes. In addition, SSH includes the capabilities to forward to arbitrary/changing ports over an encrypted connection.

SSH starts the encrypted connection before a username and/or password are sent.

The security of public key encryption can be diminished considerably if a common key is used to initiate secure sessions across a variety of clients. If this key stays constant throughout a session, or even worse, stays the same for many sessions, it makes it much easier for someone to decrypt the original key. For example, think of what can happen with the WEP security approach for wireless connectivity. Each time an SSH session is established between a particular client and server a new session key for future sessions is established hidden by the existing encryption. This helps to limit the number of packets encrypted using any particular key. Unfortunately, I have yet to be able to determine a few things like the following.

How often are the keys changed within sessions?

Do all clients start with the same key?

Hopefully, you can think about the vulnerabilities posed by these sorts of concerns.

SSH was originally developed by a Finn named Tam Ylonen.

SSH can implement a variety of encryption approaches. SSH1 tried to make use of RSA algorithms, but they were still under patent. This helped motivate development of SSH2 which makes use of 3DES and other encryption approaches. At present, SSH can make use of a much larger variety of encryption methods such as the following.

RSA

3DES

Blowfish

IDEA

CAST128

AES256

SSH consists of the three major components listed below.

transport layer protocol

provides server authentication

confidentiality

integrity

compression

user authentication protocol

authenticates the client to the server

connection protocol

provides multiplexing of the encrypted packets into several logical (not physical) channels

SSH is very popular in Linux and UNIX environments. It is often used to establish VPNs across networks. There are a variety of vendors who have built their own SSH solutions.

SSH has not been nearly as popular on Windows based machines. But the proliferation of SSH solutions for Windows clients demonstrates how often Windows clients interact with UNIX or Linux servers.

Establishing SSH Sessions. The following diagram represents how SSH sessions are established.