Telnet has been eclipsed by two feature-laden Secure Shell protocols. But which one is best?
Many network administrators have stopped using Telnet for switch management in favor of the more secure Secure Shell (SSH) protocol. But there are two versions of SSH. Which one is best?
First, let us consider what SSH can do that Telnet cannot:
Provide a secure client-server protocol that encrypts data during transmission over a network
Offer strong authentication methods to help ensure that the client and server are communicating with trusted hosts
Prevent root access, which is typical of nonsecure network applications such as Telnet and FTP
Appear transparent to end users
Many network admins switched over to SSHv1 instead of Telnet to take advantage of these features. But SSHv1 was found to have a vulnerability that allowed hackers to run code with root access. The ironic thing about this vulnerability is that it is located in a segment of code that was introduced to defend against exploitation of certain weaknesses in the SSHv1 protocol.
So Tatu Ylönen, who wrote SSHv1 in 1995, discarded the entire protocol and started over, with SSHv2. This is one of the primary reasons SSHv1 and SSHv2 will not communicate with each other.
SSHv1 and SSHv2 share the following features:
Client programs that perform remote logins, remote command implementation, and secure file copying across a network
An extremely configurable SSH server
Several selectable encryption algorithms and authentication mechanisms
An SSH agent to cache keys for easy access
SSHv2, however, provides a number of features that make it a stronger, more comprehensive product. These include:
Encryption ciphers, such as Triple Data Encryption Standard (3DES) and AES
The use of sound cryptographic MAC algorithms for integrity checking
SSHv2 is certified under the FIPS 140-1 and 140-2 NIST/U.S. government cryptographic standards. SSHv2 also replaced TFTP with SFTP for file transfer.
A common misconception is that SFTP is simply FTP run over SSH. In fact, SFTP is a new protocol designed from the beginning by the IETF SECSH working group. The protocol itself does not provide authentication and security; it expects the underlying protocol to secure this. This is why SFTP is most often used as a subsystem of SSHv2.
Remember that SFTP replaces Trivial File Transfer Protocol (TFTP). So turn off TFTP on your switches. Compared to the earlier SCP, which allows only file transfers, the SFTP protocol allows for a range of operations on remote files -- it is more like a remote file system protocol.
The extra capabilities of an SFTP client compared with those of an SCP client include resuming interrupted transfers, directory listings, and remote file removal. For the same reason, it is reasonable to implement a GUI SFTP client, but not a GUI SCP client.
We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
2017 State of IT ReportIn today's technology-driven world, "innovation" has become a basic expectation. IT leaders are tasked with making technical magic, improving customer experience, and boosting the bottom line -- yet often without any increase to the IT budget. How are organizations striking the balance between new initiatives and cost control? Download our report to learn about the biggest challenges and how savvy IT executives are overcoming them.
Infographic: The State of DevOps in 2017Is DevOps helping organizations reduce costs and time-to-market for software releases? What's getting in the way of DevOps adoption? Find out in this InformationWeek and Interop ITX infographic on the state of DevOps in 2017.