SSH is encrypted, so it is private and secure.
That’s why SSH should be used in preference to TELNET.
TELNET and SSH: The Origin Story
Necessity is the mother of invention.
Jordan Gloor / How-To Geek
System administrators needed a way to access and manage computers that were physically located elsewhere.
TELNET, short forteletype overnetwork protocol, was developed in 1969 as the answer to that problem.
SSH was created much later—in 1995—as a direct response to Telnet and other similar solutions.
The necessity this time was security.
Nowadays, SSH has almost entirely replaced TELNET.
TELNET Is a Plaintext Security Nightmare
The big problem with TELNET is it uses plaintext.
It doesn’tencryptany of its traffic, including user names and passwords.
Anything it transmits along the internet can be captured bypacket sniffingand read, with the greatest of ease.
This is a security risk even on a local internet, unless you’re the only user.
Any user can intercept TELNET traffic and obtain login credentials to which they have no right.
TELNET vs. SSH: What’s the Difference?
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.
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.
Even better, SSH can dispense with passwords altogether.It can use public key encryptionto authenticate to remote computers.
Passwords are never transmitted at all, because there’s no need to send them to the remote computer.
For example, you could access theGitHub,GitLab, andBitBuckethosted Git repositories using SSH instead of passwords.
Another advantage to using SSH over TELNET is that SSH can doreverse 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.
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.
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 see to it you are using the latest release of SSH.
Once it was discovered, in 2014, the vulnerability became known asHeartbleed.
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.
For those two years, every SSH server running the vulnerable version of OpenSSL was at risk.
Related:The Best Ways to Secure Your SSH Server
Should You Use SSH or TELNET?
It’s hard to think of why today you’d need to use TELNET vs. SSH.
That’s not the same as saying is there any scenario in which it’s safe to 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.
Related:How to Connect to an SSH Server from Windows, macOS, or Linux
