In the digital age, secure communication is paramount, especially when it comes to sensitive data and remote access to systems. One of the most critical tools that has revolutionized secure communication over the internet is SSH or Secure Shell. SSH has a rich history, and it's not without its share of vulnerabilities and best practices. In this blog, we will dive into the history of SSH, including the story of port 22, why it is recommended not to use this default port, and the notorious Heartbleed vulnerability. We will also touch upon how SecOps allows custom SSH ports for authenticated scanning, highlighting the importance of security in the world of remote access.

The Birth of SSH

To understand the significance of SSH, we must first delve into its origins. SSH was created as a response to the need for secure remote access to Unix-like systems, which were becoming increasingly popular in the early days of the internet. Before SSH, insecure methods like Telnet and rlogin were commonly used for remote access, making it easy for malicious actors to intercept sensitive data.

The story of SSH begins with a Finnish researcher named Tatu Ylönen in 1995. Tatu Ylönen was motivated to create a more secure alternative to Telnet, which was vulnerable to eavesdropping and tampering. Ylönen developed SSH as a solution to these vulnerabilities and initially named it Secure Shell. SSH1 and SSH2 protocols soon followed, each with its own set of improvements.

The Story of Port 22

SSH was designed to take the place of FTP (port 21) and telnet (port 23). The open port was 22. It was neatly located between the telnet and FTP ports. So it was reasoned that possessing that port number might be one of those insignificant details that would lend credibility. However, the main question was how to get that port number. and here's the fascinating part: he knew someone who had the authority to allocate port numbers.

In those early days of the Internet, port numbers were allocated by the esteemed Internet Assigned Numbers Authority (IANA), overseen by prominent figures like Jon Postel and Joyce K. Reynolds. Jon Postel, in particular, had an impressive list of accomplishments, having been the editor of foundational internet RFCs, including IP (RFC 791), ICMP (RFC 792), and TCP (RFC 793). To many, Jon Postel was an intimidating figure due to his contributions to internet standards.

With the vision of SSH in mind and the need for a suitable port, Tatu Ylonen contacted IANA and requested Port 22 for SSH, paving the way for this new, secure communication protocol. 

The following mail was written by Tatu Ylonen to IANA for port 22:

However, using port 22 for SSH services has its disadvantages. It has become a known target for automated scans and brute-force attacks. Malicious actors continuously scan the internet for systems listening on port 22, hoping to find vulnerable SSH servers. This is why it is highly recommended not to use the default port 22 for your SSH services.

To change the default SSH port, you can modify the SSH server configuration file, typically located at /etc/ssh/sshd_config on Unix-like systems. By changing the Port directive to a custom port number (e.g., Port 2222), you can make it more challenging for attackers to find your SSH service.

Using a custom SSH port does not make your system immune to attacks, but it can significantly reduce the number of automated scans and brute-force attempts, enhancing the security of your system.

The Heartbleed Vulnerability

While SSH has a reputation for security, no system is entirely invulnerable. In 2014, a severe security flaw called the Heartbleed vulnerability sent shockwaves through the tech community. This vulnerability did not affect SSH directly but had a significant impact on another essential security protocol - SSL/TLS.

Heartbleed was a bug in the widely used OpenSSL library, which is responsible for secure data transmission over the internet. This bug allowed attackers to read sensitive data from the memory of a web server. Heartbleed gained notoriety because it could potentially expose private keys used for SSL/TLS encryption.

The SSH protocol itself was not directly affected by Heartbleed. However, it served as a stark reminder of the importance of regularly updating and patching security software and protocols. When such a major vulnerability is discovered, it is crucial to act swiftly to mitigate the risk and prevent potential data breaches.

Following is the Heartlbleed Vulnerability CVE detail calculated from the EPSS calculator:

Heartbleed CVE: CVE-2014-0160

EPSS Score: 97.59%

CPR Score: 87.66%

Severity: High

Severity Score: 7.5

Summary: The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packets, which allows remote attackers to obtain sensitive information from process memory via crafted packets that trigger a buffer over-read, as demonstrated by reading private keys, related to d1_both.c and t1_lib.c, aka the Heartbleed bug.

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

CWE ID: CWE-125

You can use SecOps Solution to find if your servers/VM/endpoints are impacted by Heartbleed it also supports SSH-based authenticated scans to identify vulnerabilities.

The Evolution of SSH

SSH has evolved significantly since its inception. SSH1 was the initial version of the protocol, but it had its share of security issues and limitations. This prompted the development of SSH2, which addressed these shortcomings and became the widely adopted standard.

SSH2 introduced numerous security improvements, including stronger encryption algorithms, better key exchange protocols, and enhanced security features. It is important to note that SSH1 is considered less secure and is no longer recommended for use. SSH2 has become the de facto standard for secure remote access and file transfer.

Over the years, SSH has continued to advance, with various implementations and open-source projects contributing to its development. Today, SSH is a critical tool for secure communication, remote administration, and secure file transfers, playing a pivotal role in the cybersecurity landscape.

The Importance of SSH

SSH's significance in the world of secure communication and remote access cannot be overstated. It offers a robust and reliable method for system administrators and developers to manage servers, transfer files, and interact with remote systems securely. Some key benefits of SSH include:

1. Encryption: SSH encrypts the data transferred between client and server, making it extremely difficult for malicious actors to intercept and decipher the communication.

2. Authentication: SSH uses various authentication methods, including passwords, key pairs, and multi-factor authentication, to verify the identity of users and systems. 

3. Secure File Transfer: Tools like SCP (Secure Copy Protocol) and SFTP (SSH File Transfer Protocol) provide secure file transfer capabilities.

4. Tunneling: SSH can create secure tunnels for forwarding traffic, enabling remote access to services running on the target server.

5. Port Forwarding: SSH allows users to forward local and remote ports, facilitating various networking and access scenarios.

6. Secure Communication: SSH can secure various network protocols, ensuring that data remains protected in transit.

SSH has become a foundational technology for secure access and data transfer in the modern IT landscape, making it a vital tool for businesses, system administrators, and developers alike.

Conclusion

SSH has come a long way from its humble beginnings in the mid-1990s. It has played a pivotal role in securing remote access to systems and facilitating secure communication in the digital age. 

The history of SSH is a story of innovation and adaptation in the face of evolving security challenges. As technology advances, so do our approaches to security, and SSH continues to be a cornerstone in this ongoing journey. Whether you're a system administrator, developer, or simply a user looking for secure access to remote systems, SSH remains a powerful and reliable tool for all your secure communication and remote access needs.

‍

SecOps Solution is an award-winning agent-less Full-stack Vulnerability and Patch Management Platform that helps organizations identify, prioritize and remediate security vulnerabilities and misconfigurations in seconds.

To schedule a demo, just pick a slot that is most convenient for you.