54-Day Open SSH Port Experiment: Who Tried to Access It?

54-Day Open SSH Port Experiment: Who Tried to Access It?

On April 26, 2026, a report from the tech community drew significant attention. Developer Arman B. published a blog post titled “I Left Port 22 Open on the Internet for 54 Days. Here’s Who Showed Up,” in which he detailed his experiment of leaving SSH (Secure Shell) Port 22 — the standard port for SSH — exposed to the internet for 54 days. The results included a massive number of access attempts and attacks, underscoring the pressing reality of security concerns in cloud environments and remote server management.

Background of the Experiment: Why Expose an SSH Port?

SSH is widely used as a protocol to provide secure connections to remote servers. However, its popularity also makes it a primary target for automated attacks. Many developers and system administrators take measures such as closing the SSH port or restricting access to key-based authentication, but it is hard to grasp the actual level of threats in the internet space without experiencing it firsthand.

Arman’s experiment aimed to empirically answer this question. Using his own cloud server (likely a VPS or cloud instance), he intentionally left SSH Port 22 open to public networks and recorded access logs in detail over a period of 54 days. During this time, the server remained fully exposed to the internet.

Experiment Results: A Flood of Automated Attacks

The recorded data was shocking. Over the course of 54 days, tens of thousands of connection attempts were logged, most of which came from automated scanners and bots. The following patterns were particularly notable:

1. The Onslaught of Brute Force Attacks: The most frequent type of attack involved brute force attempts to guess username and password combinations. The logs showed endless attempts using common usernames such as admin, root, and test, paired with dictionary-based password lists. The attacks originated from a wide range of distributed IP addresses, with a massive number of requests flooding the server in short periods. This method is often used to automatically identify misconfigured SSH servers and incorporate them into a botnet for malicious purposes like zero-day attacks.

2. Exploitation of Vulnerabilities: There were attempts to exploit vulnerabilities in the SSH software itself. Scans targeting known vulnerabilities in specific software versions were detected, with attackers employing more sophisticated techniques to gain unauthorized access.

3. Suspicious Connection Requests: Despite the absence of legitimate user connections, the server continually received connection requests. These included probes attempting to gather SSH version information and efforts to execute shell commands post-connection.

Arman described these attacks as “a mirror reflecting the dark side of the internet.” Although his server was secured with robust configurations (key-based authentication, firewall rules blocking malicious IPs, etc.), it was clear that the psychological burden of monitoring the logs was immense.

The Reality Behind the Threats

The findings from this experiment go beyond a personal anecdote, offering significant insights into the overall security landscape of the internet.

• The Industrialization of Automated Attacks: Most of the attacks were not manual but executed by automated tools, signaling lower attack costs and greater scalability. Attackers indiscriminately scan vulnerable cloud servers to hijack them for botnets, which can then be used for activities like DDoS attacks or cryptocurrency mining.

• The Danger of “Implicit Consent”: Many developers are either unaware that their cloud provider’s default settings leave the SSH port open or mistakenly believe that being attacked is unlikely. Arman’s experiment underscores that servers are continuously monitored and that anyone can become a target.

• Legal and Ethical Considerations: While this experiment was conducted on a personal server, exposing it to the internet carries risks of unintentionally becoming a stepping stone for attacks on others. This highlights the importance of adhering to ethical guidelines in security research.

Implications for Security and Lessons Learned

The lessons from this experiment are clear: strengthening SSH access security is essential. Specific recommendations include:

• Mandatory Key-Based Authentication: Disable password-based authentication and permit only public key cryptography. This alone can effectively block brute force attacks.
• Use of Firewalls and Security Groups: Restrict access to the SSH port to trusted IP addresses. In cloud environments, security groups should strictly control incoming traffic.
• Deploy Tools Like Fail2ban: Implement mechanisms to automatically detect and block unauthorized connection attempts for a certain period.
• Change the SSH Port: Switch from the default port 22 to a non-standard port. This simple step can significantly reduce automated scans by amateur attackers.
• Regular Audits and Log Analysis: Continuously monitor access logs to detect unusual patterns early.

Looking Ahead: A “New Normal” for Security

Arman’s experiment serves as a reminder to revisit the basics of security in the cloud-native era. As zero-trust architecture and AI-powered anomaly detection systems become more prevalent, there is a risk of neglecting fundamental security measures.

In the future, the SSH protocol itself may evolve, with potential improvements like built-in stronger authentication mechanisms or standardized automated threat response features. However, beyond technological advancements, it is crucial to enhance the security awareness of developers and administrators.

This experiment vividly illustrates, with concrete data, just how vulnerable the internet environment is to attacks. Every tech professional should always keep in mind that their infrastructure could be “the next target.”

FAQ

Q: What specific risks arise from leaving an SSH port exposed?
A: The primary risk is unauthorized access through automated brute force attacks. Attackers use dictionary-based password attempts to gain entry, potentially compromising the server for malicious activities such as hosting malware or mining cryptocurrency. There is also the risk of exploitation through known vulnerabilities, leading to data breaches or system damage.

Q: What is the most effective way to secure SSH access?
A: The most effective method is to disable password-based authentication and rely solely on key-based authentication. Additionally, restricting SSH port access to trusted IP addresses via a firewall, using tools like Fail2ban to block unauthorized attempts, and changing the default SSH port from 22 can further enhance security.

Q: Are the results of this experiment applicable to cloud environments?
A: Yes, the findings are highly relevant to cloud environments, which are often directly exposed to the internet and therefore more susceptible to attacks. It is crucial to configure cloud provider security groups effectively, tightly controlling incoming traffic and taking responsibility for securing your infrastructure.