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.
5 Top Federal Initiatives For 2015As InformationWeek Government readers were busy firming up their fiscal year 2015 budgets, we asked them to rate more than 30 IT initiatives in terms of importance and current leadership focus. No surprise, among more than 30 options, security is No. 1. After that, things get less predictable.