TELNET doesn’t have any encryption, so everything is transmitted in plaintext. SSH is encrypted, so it is private and secure. That’s why SSH should be used in preference to TELNET.
SSH and TELNET both let you connect to remote, networked computers and to use them as if you’re sitting in front of them. So what’s the difference between these two venerable protocols, and is there really always an 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 impractical or inconvenient for the administrator to position themselves in front of the computer, they needed a way to access the remote computer that allowed them to issue commands just as if they were typing them into that computer.
TELNET, short for teletype over network protocol, was developed in 1969 as the answer to that problem. As long as the remote computer was network accessible, it allowed the administrator, or any other authorized person, to connect to it and use it as if they were physically pressing the keys of the remote keyboard.
SSH was created much later—in 1995—as a direct response to Telnet and other similar solutions. The necessity this time was security. TELNET, rlogin, FTP, and other protocols of that era were designed without any consideration to, or perceived need for, security.
SSH stands for secure shell, so you can see that security was a guiding principle from its inception. Nowadays, SSH has almost entirely replaced TELNET.
TELNET Is a Plaintext Security Nightmare
The big problem with TELNET is it uses plaintext. It doesn’t encrypt any of its traffic, including user names and passwords. Anything it transmits along the network can be captured by packet sniffing and read, with the greatest of ease. This is a security risk even on a local network, unless you’re the only user. Any user can intercept TELNET traffic and obtain login credentials to which they have no right.
If the remote computer is off-site, requiring a connection to be made across the internet to reach it, the problem is magnified immeasurably. TELNET was a product of its time, and to be fair to them, the authors almost certainly didn’t expect people to be using it well over fifty years later, in today’s vastly different IT landscape.
While TELNET deserves its place on the list of important programs that collectively helped bring us to where we are today, it’s not something that we should still be using in today’s world.
How Is SSH Different From TELNET?
On the face of it, TELNET and SSH are two answers to the same problem. They both let you access a terminal window on a remote computer and issue commands to it. But because SSH was developed so much later than TELNET, the problem was more thoroughly understood, and the answer was better engineered.
TELNET was designed with private networks in mind, but SSH was designed to cope 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 can’t be changed. By default, SSH uses port 22, but this can be configured and changed. Configuring SSH to use an unobvious port number makes it harder for attackers to identify the SSH port. If SSH port can be identified, it’s a trivial matter to mount a brute-force attack where thousands of passwords harvested from data breaches are tried in turn, by automated software.
Even better, SSH can dispense with passwords altogether. It can use public key encryption to authenticate to remote computers. Passwords are never transmitted at all, because there’s no need to send them to the remote computer. Its data encryption and SSH key authentication mean SSH is able to deliver secure connections and communications over insecure networks like the internet.
In fact, SSH can be used to authenticate with different services, not just remote computers running an SSH server. For example, you can access the GitHub, GitLab, and BitBucket hosted Git repositories using SSH instead of passwords.
Another advantage to using SSH over TELNET is that SSH can do reverse SSH tunneling. This requires the server to establish a connection with the client computer. Until the local user wants to make 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 their own computer. SSH sends the connection down the already established connection, to the server. This provides a private tunnel inside the already encrypted connection from the server to the client.
The only win for TELNET is it uses less bandwidth. But this isn’t 1969 where bandwidth was scarce, and SSH isn’t exactly a bandwidth hog either.
SSH Has Had Its Problems, Too
Although SSH outdoes TELNET when it comes to security, we have to remember that it is still software, and software can have bugs. Those bugs can lead to vulnerabilities that can be exploited by cybercriminals. Also, encryption standards and algorithms change over time, and get superseded. Like all encryption-based software, as older versions of SSH age, they can become less secure. That’s why it is important to make sure you are using the latest release of SSH.
The version of SSH used in most Linux computers is OpenSSH, an implementation of SSH that builds upon 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 to specify how much data to contain in the answer.
They could requests a response of (say) 64KB when the actual response would have needed no more than 64 bytes. The first sequence of bytes in that data would be the genuine, expected response, followed by whatever happened to be in the memory recently used by OpenSSL. What was contained in that data was pot luck, but it could contain sensitive information such as session cookies and passwords, or other information that allowed an attacker to acquire private keys, for example.
Once it was discovered, in 2014, the vulnerability became known as Heartbleed. It was quickly fixed in the software. However the vulnerability doesn’t disappear at that point. The vulnerability is only completely nullified when all computers running the vulnerable software have the fixed version installed. In other words, when the computers have been patched. Because many administrators were slow to react, the uptake of the fixed software was slow.
Also worrying is the two years between 2012 when the bug was introduced and 2014 when it was discovered, and addressed. For those two years, every SSH server running the vulnerable version of OpenSSL was at risk.
To be fair, that happened practically a decade ago, and since then there have been many releases, improvements, bug fixes and code reviews.
RELATED: The Best Ways to Secure Your SSH Server
Should You Use SSH or TELNET?
It’s hard to think of a reason you’d need to use TELNET today. That’s not the same as saying is there any scenario in which it’s safe to use TELNET. In a self-contained network that isn’t connected to the outside world, and you’re sure no one is going to packet-sniff your traffic, you could use TELNET. But there’s no reason to. The security trade-off can’t be justified.
SSH is more secure and more flexible—that’s the advantage to using SSH over TELNET. The OpenSSH implementation is free for all uses including commercial, and is available for all popular operating systems.
