How is SSH different from Telnet?

TELNET does not have any kind of encryption, so everything is transmitted in plain text. SSH is encrypted, so it’s private and secure. That is why SSH should be used instead of TELNET.

Both SSH and TELNET allow you to connect to remote computers on the network and use them as if you were sitting in front of them. So what is the difference between these two venerable protocols? Is there really always any advantage to using SSH over TELNET?

TELNET and SSH: The Origin Story

Necessity is the mother of invention. System administrators needed a way to access and manage computers that were physically located elsewhere. If it was not practical or inconvenient for the administrator to stand in front of the computer, they needed a way to access the remote computer that would allow them to issue commands as if they were typing them on that computer.

TELNET, short for phonewrite about networking protocol, was developed in 1969 as a response to that problem. As long as the remote computer was accessible over the network, it allowed the administrator, or any other authorized person, to connect to it and use it as if they were physically pressing the keys on the remote keyboard.

SSH was created much later, in 1995, as a direct response to Telnet and other similar solutions. The need this time was security. TELNET, rlogin, FTP, and other protocols of that era were designed without any consideration or perceived need for security.

ssh means yessecure shOkay, so you can see that security was a guiding principle from its inception. Today, SSH has almost completely replaced TELNET.

TELNET is a plain text security nightmare

The big problem with TELNET is that it uses plain text. It does not encrypt any of your traffic, including usernames and passwords. Anything you transmit over the network can be most easily captured and read using packet sniffing. This is a security risk even on a local network, unless you are the only user. Any user can intercept TELNET traffic and obtain login credentials to which they are not entitled.

If the remote computer is offsite, requiring a connection over the Internet to reach it, the problem is greatly magnified. TELNET was a product of its time and, to be fair to them, the authors almost certainly did not expect people to use it more than fifty years later, in today’s very different IT landscape.

While TELNET deserves its place on the list of important programs that collectively helped us get to where we are today, it’s not something we should continue to use in today’s world.

How is SSH different from TELNET?

At first glance, TELNET and SSH are two answers to the same problem. Both allow you to access a terminal window on a remote computer and send commands to it. But because SSH was developed much later than TELNET, the problem was more fully understood and the response was better designed.

TELNET was designed with private networks in mind, but SSH was designed to deal with public networks and the need to maintain privacy and security when transferring data and making remote connections.

TELNET uses port 23 and that port number cannot be changed. By default, SSH uses port 22, but this can be configured and changed. Configuring SSH to use a non-obvious port number makes it more difficult for attackers to identify the SSH port. If the SSH port can be identified, it is a trivial matter to mount a brute force attack where thousands of passwords obtained from data breaches are tested in turn by automated software.

Even better, SSH can do without passwords entirely. You can use public key encryption to authenticate to remote computers. Passwords are never transmitted at all, because they don’t need to be sent to the remote computer. Its data encryption and SSH key authentication mean that SSH can provide secure connections and communications over insecure networks like the Internet.

In fact, SSH can be used to authenticate with many different services, not just remote computers running an SSH server. For example, you can access Git repositories hosted on GitHub, GitLab, and BitBucket using SSH instead of passwords.

Another advantage of using SSH over TELNET is that SSH can reverse SSH tunnel. This requires the server to establish a connection to the client computer. Until the local user wants to establish a connection to the server, the connection is ignored.

When the client wants to connect to the server, the user establishes an SSH connection to his own computer. SSH sends the connection over the already established connection, to the server. This provides a private tunnel into the already encrypted connection from server to client.

The only advantage of TELNET is that it uses less bandwidth. But this isn’t 1969, where bandwidth was at a premium, and SSH isn’t exactly a bandwidth hog, either.

SSH has had its problems too

Although SSH outperforms TELNET when it comes to security, we must remember that it is still software, and software can be buggy. Those bugs can lead to vulnerabilities that cybercriminals can exploit. Also, encryption standards and algorithms change over time and are superseded. Like all encryption-based software, as SSH versions age, they can become less secure. That’s why it’s important to make sure you’re using the latest version of SSH.

The version of SSH used on most Linux computers is OpenSSH, an implementation of SSH that is based on the OpenSSL toolkit and libraries. In 2012, the OpenSSL library accidentally introduced a bug that allowed an attacker to request a response from the SSL server and specify how much data to contain in the response.

They might request a response that is (say) 64KB when the actual response would have required no more than 64 bytes. The first sequence of bytes in that data would be the genuine and expected response, followed by whatever happened in memory recently used by OpenSSL. What that data contained was luck, but it could contain sensitive information, such as session cookies and passwords, or other information that would allow an attacker to acquire private keys, for example.

Once discovered, in 2014, the vulnerability became known as Heartbleed. Quickly fixed in software. However, the vulnerability does not disappear at that point. The vulnerability is only fully nullified when all computers running the vulnerable software have the patched version installed. In other words, when computers have been patched. Because many administrators were slow to react, uptake of the fixed software was slow.

Also of concern are the two years between 2012, when the bug was introduced, and 2014, when it was discovered and fixed. During those two years, all SSH servers running the vulnerable version of OpenSSL were at risk.

To be fair, that was almost a decade ago, and since then there have been many releases, enhancements, bug fixes, and code revisions.

RELATED: The best ways to protect your SSH server

Should you use SSH or TELNET?

It’s hard to think of a reason why you would need to use TELNET today. That’s not the same as saying if there are any scenarios where it’s safe to use TELNET. On a stand-alone network that is not connected to the outside world, and you are sure that no one will be tracking your traffic, you could use TELNET. But there’s no reason to. The security tradeoff cannot be justified.

SSH is more secure and more flexible: that’s the advantage of using SSH over TELNET. The OpenSSH implementation is free for all uses, including commercial, and is available for all popular operating systems.

RELATED: How to connect to an SSH server from Windows, macOS or Linux