News
Commentary
11/19/2007
02:34 PM
Commentary
Commentary
Commentary
50%
50%

Battle of the SSH Protocols: SSHv1 v SSHv2

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
  • Support for public key certificates, also known as digital certificates

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.

Previous
1 of 2
Next
Comment  | 
Print  | 
More Insights
Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Tech Digest, Dec. 9, 2014
Apps will make or break the tablet as a work device, but don't shortchange critical factors related to hardware, security, peripherals, and integration.
Video
Slideshows
Twitter Feed
InformationWeek Radio
Archived InformationWeek Radio
Join us for a roundup of the top stories on InformationWeek.com for the week of December 14, 2014. Be here for the show and for the incredible Friday Afternoon Conversation that runs beside the program.
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.