To understand the purpose and importance of SSH’s, it’s valuable to know about the Teletype Network (Telnet) protocol. Telnet was developed in 1969 as a simple command line tool (no GUI) that enabled commands to be sent remotely to a server. One could administrate a server from miles away as if sitting right in front of it. Running programs, managing folders and files, browse directories, and starting/stopping services become possible to accomplish remotely with this protocol.
When Telnet came about in the pre-internet era, security wasn’t a major concern. Hence the protocol’s design to send commands in clear text without encryption wasn’t an issue. Unfortunately, this lack of security became problematic when people started making transfers over the internet. As data is sent through the internet, it makes its way through many networks to make a remote connection. This leaves data vulnerable to possibly going through a machine that’s unsecure or has malicious programs/users listening for interesting requests. By using Telnet over the internet, someone could easily eaves drop and grab any sensitive data being sent across its network. Some still use this protocol but largely in a LAN for obvious reasons. Telnet is outdated and shouldn’t be used over the public internet.
The need for a secure, Telnet-like protocol led Secure Shell Protocol (SSH) to gain quick popularity once created in 1995. SSH is a cryptographic protocol that provides a secure access to computers over an unsecure network.
With its strong encryption, SSH is often used by network admins to access remote assets. Managing systems and applications, interacting with the command line, delivering software patches, etc. no longer require the admin to be in-person.
SSH can be used by any Linux or macOS user. And Windows users pre-Windows10 (which has SSH compatibility built into it) can take advantage of something called PuTTY. PuTTY is a free and open-source terminal emulator application which supports several network protocols (including SSH).
There are two main versions of SSH. Due to the incompatibility of the first two, the came into play.
SSH-1
This is the original version of SSH invented by Tatu Ylönenin response to a password-sniffing attack at his university (Helsinki University of Technology, Finland). SSH-1 was released in July 1995 as a free protocol, and by the end of the year its user base had reached 20,000 in across 50 countries. However, there were some serious security issues with this version…
SSH-2
Including many significant improvements over SSH-1, this version was introduced in 2006 as a standard by the Internet Engineering Task Force (IETF). SSH-2 also supports SFTP (a secure version of FTP). This is the most common version used today.
SSH-1.99
As SSH-2 was designed completely from scratch, SSH-1 andSSH-2 are incompatible with each other. Also published in 2006, the SSH-1.99 “version” provides backward compatibility for SSH-2 with SSH-1.
SSH uses a client-server model authenticating two parties and encrypting the data between them. An SSH session is established in two stages. First, an encryption method is agreed upon and established to protect future communication. Second, the user is authenticated and access to the server is decided whether to be granted.
Handshake / Server Authentication
The server side listens for connections on a designated port (port 22 by default). Once the client side makes the initial transmission control protocol (TCP) handshake with the server responds with the SSH versions it supports. If the client matches one of the versions, the connection continues. Simultaneously, the server provides its public host key for the client to authenticate the server’s identity as its intended host. This is done by comparing the key against a local database or receiving the verification from a Certified Authority
Session Key
From here, both sides negotiate a session key using (aversion of) the Diffie-Hellman (DH) algorithm. DH enables two sides to use a public key to encrypt and decrypt a conversation/data using symmetric cryptography. Basically, this algorithm (and its variants) enables each party to combine their own private data (private keys) with public data (public keys) from the other system for their identical secret session key. This session key will be used to encrypt the entire session. This shared participation in generating the secret key keeps all further communication from being deciphered by outsiders.
Client Authentication
Once the session encryption is established, the client’s user access must be authenticated to connect to the server. Based on what the server accepts, there are a few ways to do this. Password authentication is one of these. This is where the server prompts the client for a password of the account they’re logging into. Since the password is sent through the already negotiated encryption, it’s secure from outside parties. However, too often automated scripts can break passwords, so this method isn’t recommended.
A popular alternative to password authentication is the use of SSH key pairs. This method is a sequence of interactions between the client and server:
- The client sends an ID for the key pair it’d like to authenticate with to the server.
- The server checks the authorized_keys file of the account the client is attempting to log into for the key ID. If a public key with the matching ID is found, the server generates a random number, uses the public key to encrypt this number, and sends it over to the client.
- If the client has the associated private key,it will be able to use it to decrypt the message (revealing the original generated number).
- The client then combines the decrypted number with the shared session key (which is encrypting the communication) and calculates the MD5 hash of this value. MD5 is a message-digest algorithm that uses the hash function to generate a 128-bit hash value (32 characters long in hexadecimal). This MD5 hash is sent back to the server as an answer to the encrypted number message it sent.
- The server then also uses the shared session key and original generated number that it sent to the client to calculate the MD5 value on its own. The client compares this calculation to the one that the client sent back. These two values should be the exact same. If so, this verifies the client held the private key and authenticates them!
* To clarify, the public and private key pairs used for the symmetric encryption to produce the shared session key are separate from the SSH keys used to authenticate a client to the server.
If the server can authenticate the connecting client, it spawns the environment for the client to interact with it.
Now you have a grip on the SSH protocol and its importance! For more information like this, check out our other posts below!
