SSH protocol explained
The first step to answering the question, “How does SSH work?” is gaining a clear view of how it interacts with other internet protocols to accomplish network services.
SSH works within a network through a client/server architecture. An SSH client is the program that runs SSH protocol from a specific device in order to access remote machines, automate data transfers, issue commands, and even manage network infrastructure. The client/server model means that the network system components being used to establish an SSH secure connection must be enabled for SSH. This can mean installing the proper software, or simply utilizing the SSH services program the computer has built in.
Next, it’s crucial to understand the layers within and around SSH referred to as the protocol stack. SSH has three components: transport layer protocol (TLP), user authentication protocol, and connection protocol. The three layers do the following:
- Transport layer protocol: The TLP serves to authenticate the server and establish confidentiality and integrity. According to the Request for Comments (RFC) memo 4251, TLP should be held to a standard of perfect forward secrecy. In essence, even if a compromise were to happen during one session, it would not affect the security of past sessions. Perfect forward secrecy (PFS) represents significant progress in data transfer protocol, because it means that even if the server’s private key were to fall into the wrong hands a hacker would not be able to retroactively gain access to previously transmitted data. With PFS, each new session is independently secure, assuring that the total confidentiality of past sessions remains intact.
- User authentication protocol: As indicated by its title, the user authentication protocol authenticates the user to the server, confirming the identity of the agent operating as the client.
- Connection protocol: The connection protocol mutiplexes the SSH tunnel. In other words, the connection protocol creates distinct data streams, or logical channels, from a single client/server connection.
The sequential actions of these three protocol layers allow the SSH protocol to successfully secure connections, encrypt data, and transfer data along different channels.
How TLP works
The TLP effectively exchanges and secures data by 1) authenticating the server, 2) negotiating the encryption, and 3) determining the master key to decryption.
An SSH security process begins when the client attempts to connect to the SSH server. SSH protocol uses public key cryptography to authenticate the server, meaning the server sends its public key to the client for confirmation. The client is able to authenticate the server by comparing this host key against a local database or by receiving the verification of a Certified Authority (CA).
After the server has been authenticated, the encryption algorithm negotiation begins. Both the client and the server share their supported encryption protocols, ordered by preferability. The entry with the highest server preference that is shared across both client and server wins, making it the algorithm used to encrypt the session.
Finally, once the two parties have agreed upon the encryption algorithm, they can determine the master key. SSH-2 uses the Diffie–Hellman key exchange method, in which the client and server apply the encryption algorithm to create a shared secret and perform symmetrical encryption.
Although the details of a Diffie–Hellman key exchange are quite complex in action, here’s a basic overview of how symmetrical encryption operates to successfully secure data.
- The client and server select a seed value—a large prime number.
- They apply the encryption algorithm to the seed value.
- Next, both the client and the server generate another prime number that acts as their personal private key.
- The private key and the shared number go through the algorithm to produce a public key that each machine sends to the other.
- Using their own private key, the public key of the other party, and the original seed value, both sides compute a shared key—the master key.
- The end result is a shared master key that can be used by both client and host to encrypt and decrypt data. The process is thus symmetrical, allowing both sides to encrypt and decrypt while keeping their private key a secret.
After the key exchange, the client sends a service request to initiate either user authentication or connection protocol.
How user authentication works
User authorization can take several forms. The client sends a user authentication service request that specifies the method of authentication—asymmetrical key authentication, passwords, or host-based verification.
Many SSH users depend on the password method, which is completely acceptable in some environments. However, passwords are considered slightly less secure because although they are encrypted when transmitted, bots can use brute-force attacks or default passwords to gain access to a secure session.
An asymmetrical key authentication method relies on SSH key pairs, which do not require a password and thus avoid the possibility of exploitation. In a host-based system, the host has authenticated its clients and essentially vouches for them. The server then must only authenticate the host’s identity, simplifying user authentication for a host with multiple clients.
Is SSH Completely Secure?
Given constant new threats in the field of cybersecurity, many MSPs want to know the security level of SSH protocol. As with most security measures, the answer is nuanced.
As previously mentioned, SSH-2 was developed in part to address the vulnerabilities of SSH-1. Its improvements include the implementation of the Diffie–Hellman key exchange method and its inclusion of message authentication codes as an additional data integrity measure. These security features make it incompatible with SSH-1, and so far no one has been able to confirm a methodology that could exploit SSH-2.
That being said, there is good reason to believe that SSH-2 has its weaknesses. The primary evidence suggesting that even SSH-2 can be decrypted by unauthorized agents is Edward Snowden’s successful 2013 National Security Agency (NSA) information leak. Although the method he used to accomplish this is unclear, the leak itself attests to the possible violability of SSH-encrypted data.
Ultimately, this breach was the product of a rare combination of circumstances—governmental power, abundant funding, and political motive. For most MSPs, SSH-2 protocol is highly secure and more than adequate for the typical business environment.
Is SSH over TCP or UDP?
SSH usually runs over TCP. That being said, RFC 4251 specifies that SSH transmission layer protocol “might also be used on top of any other reliable data stream”.
SSH protocol’s default settings are to listen on TCP port 22 for connections. Although this number can be reconfigured as necessary, RFC 4253 states that “this port number has been registered with the IANA, and has been officially assigned for SSH.”
Using TCP, SSH is able to accomplish port tunneling and forwarding. These techniques allow data to travel on an unsecured network to a private network by encrypting the data and obscuring the traffic type. This is incredibly useful for those who are trying to benefit from an internet service restricted by the network firewall—although of course it must be used with the proper precautions by authorized users.
The SSH bottom line
SSH has come a long way—from revolutionizing remote logins by making Telnet fairly obsolete, to developing its second major version to eradicate its own vulnerabilities. As a result, SSH has become a fundamental component of networking services, facilitating secure and interactive file transfer, remote monitoring, command execution, tunneling, and more. As SSH moves forward in a world plagued by cyberattacks, MSPs must stay alert to emerging procedures that strive to exploit yet unknown vulnerabilities.
To this end, continuing to learn about SSH protocol architecture and methodology is a great approach to maintaining security and safeguarding network health.
For more tips and advice on networking, check out our blog.