Getty Images/iStockphoto
SSH2 vs. SSH1 and why SSH versions still matter
The Secure Shell protocol, SSH, was redesigned and released as SSH2 in 2006. While SSH1 lingers for legacy uses, find out how the protocols differ and why it's important.
Secure Shell uses cryptography to provide a secure means of connecting computers over an inherently insecure medium. One of the most common uses of SSH is to facilitate remote login sessions between an authorized user and a trusted host over the internet. With the release of SSH2 in RFC 4253, The Secure Shell (SSH) Transport Layer Protocol, users have the benefit of added functionality and security.
From the time Finnish network security expert Tatu Ylönen created the protocol in 1995, SSH became the go-to secure protocol for public key authentication of remote terminal sessions, file transfers and many other types of network connections. The SSH protocol enables user authentication methods based on public key cryptographic algorithms and has largely supplanted older network protocols lacking in such mechanisms, including Telnet, remote login and remote shell.
In 1995, SSH protocol version 1, as well as the original secure shell, or ssh, implementation of that protocol, were published. SSHv1, also known as SSH1 or SSH v1, the original version of the protocol, was published as an open source specification in 1996, but the original SSH implementation was offered as a commercial product by SSH Communications Security Corporation, which was founded by Ylönen.
In 2006, the Internet Engineering Task Force (IETF) published the specification for SSHv2, also known as SSH2 or SSH v2, as a proposed internet standard. While the purpose and functions of the new SSH protocol version are the same as the old one, the two protocols are otherwise quite different.
No one should be making an SSH connection with older implementations based on SSH1 anymore, but it is worth knowing the differences between SSH1 and SSH2 and how to deal with SSH versioning in the field.
Differences between SSH2 and SSH1
When comparing SSH2 to SSH1, it's important to note that SSH2 is not simply SSH1 with new protocols plugged in. It's a complete rewrite of the original protocol that incorporates built-in protections against known vulnerabilities in SSH1.
The major differences between SSH1 and SSH2 fall into two main categories: technical and licensing. Technically, SSH2 uses different encryption and authentication algorithms. SSH1 supported four encryption algorithms, two of which had been found to be insecure. SSH1 symmetric key block encryption algorithms included the following:
- Data Encryption Standard (DES) is an obsolete U.S. federal standard for encryption adopted in 1977, withdrawn as outdated by NIST in 2005 after it was replaced with the Advanced Encryption Standard (AES) in 2001.
- Triple DES, also known as the Triple Data Encryption Standard or 3DES, is an improved version of the DES block encryption algorithm that applies the DES algorithm three times to encrypted data. NIST has deprecated 3DES for new uses, and its use will be forbidden after 2023.
- The International Data Encryption Algorithm (IDEA) is an algorithm first described in 1991 and intended to replace DES. The patent for IDEA has expired, and the algorithm is freely available for all uses.
- Blowfish is an encryption algorithm first described in 1993. It was intended as a general-purpose symmetric key block encryption algorithm to replace DES.
SSH2 dropped support for DES and IDEA encryption algorithms because they were found to be subject to successful attacks. SSH2 currently supports the following encryption algorithms:
- AES
- Blowfish
- 3DES
- CAST-128 is an encryption algorithm first described in 1996 as an alternative candidate for replacing DES. It is currently used in Pretty Good Privacy implementations, including the GNU Privacy Guard program.
- RC4, also known as Rivest Cipher 4 or ARCFOUR, is a stream cipher first described in 1987 by Ron Rivest. It was long used in the TLS protocol, but due to numerous weaknesses, it has been deprecated for use in TLS. It is fast, however, and may be secure enough for some applications.
The newer version of the SSH protocol also added to existing authentication methods. While SSH1 used the RSA authentication algorithm, SSH2 switched to the Digital Signature Algorithm, or DSA. These changes were designed to both circumvent intellectual property issues surrounding the use of IDEA and RSA and increase the base level of security in SSH2 by using stronger algorithms for the exchange of host keys and password authentication.
SSH2 also provides added functionality. Most notably, it adds the secure file transfer protocol, or sftp, program to the SSH suite. This program uses the SSH protocol's transport layer encryption technology to provide a secure means for file transfer between remote systems. It is also rapidly approaching acceptance as an industry standard by the IETF's Secure Shell Working Group.
Versions of the SSH protocol
As defined in RFC 4253, the SSH protocol uses a protocol version exchange between SSH client and SSH server. This exchange is part of the negotiation between the SSH server and client to determine which protocol version is supported at either end of the exchange. The protoversion and softwareversion parameters contain the version of the SSH protocol supported by the server or client and the implementation version of the server or client software, respectively. The value of softwareversion usually includes the name of the implementation of the SSH client or server, along with the version of that software.
There are three meaningful values for protoversion:
- SSH-1 refers to any implementation of the first version of the SSH protocol. The client or server indicates they are using this version of the SSH protocol for any version of the protocol prior to SSH-2. This includes interim versions of the specification, such as 1.3 and 1.5, that were sometimes used before SSH-2.
- SSH-2 refers to any implementation of the second version of the SSH protocol, as defined in the IETF RFC.
- SSH-1.99 is a catch-all value, used only by SSH servers that support SSH-2 to indicate they have backward compatibility with SSH-1.
In the early days of SSH, users were able to freely download and use SSH1, despite its use of patented technologies. The new SSH2 protocol is designed to avoid intellectual property claims, while SSH Communications Security rereleased its SSH client as SSH Tectia and currently only offers free download of a 45-day free trial version of the client.
The open source community objected to this change in the SSH licensing scheme and offers OpenSSH as an alternative. An offshoot of the OpenBSD project, OpenSSH provides the same functionality as SSH2 without conflicting with any intellectual property restrictions. It may be downloaded from OpenSSH.
Modern OSes, including Windows 10 and later, macOS and Linux, include the OpenSSH implementation for use at the command line. A popular GUI version of SSH called PuTTY is also available for Windows.
Managing SSH versions
So, what does all of this mean for security practitioners? First, identify legacy uses of SSH1, and determine whether those uses can be upgraded to SSH2. While SSH1 still may be essential for special use cases, upgrading them, if possible, is important for the following reasons:
- SSH1 has not been supported by an active development community for many years. This limits the availability of future upgrades and defenses against new threats.
- SSH1 has numerous documented vulnerabilities, including susceptibility to a variant of the cryptographic man-in-the-middle attack, that have been resolved in SSH2.
Unless you have a specific reason not to upgrade, it's a prudent idea to do so.
Second, if you're not currently using any secure means to facilitate remote connections to your systems, you should look into implementing SSH2 or a similar technology immediately. It's important to remember that tools like Telnet and FTP have no built-in security. They pass usernames and passwords in plaintext and greatly undermine the security of your network.
SSH2 provides security professionals with a powerful means to facilitate secure connections. Don't forget the importance of educating your user base on the proper use of these tools.
