SSH Password Guessing
A brief public write-up of opportunistic SSH password guessing observed against markcardiff.tech. The activity is consistent with routine internet scanning rather than targeted intrusion activity.
Executive summary
Internet-facing SSH services receive constant background noise from automated scanners, botnets, and opportunistic password-guessing tools. The activity observed against this server fits that pattern.
The strongest signal was repeated password guessing against root, followed by common administrative and service usernames such as admin, user, support, deploy, oracle, postgres, and jenkins.
The observed sources included both cloud-hosted infrastructure and ISP/residential-looking address space. Several higher-volume sources mapped to Alibaba Cloud and Google Cloud. That is infrastructure context only, not actor attribution.
Top targeted usernames
Top source IPs
Timeline by day
Hourly distribution / UTC
Coarse geolocation / ASN enrichment
Geolocation and ASN data describe where an IP address is registered or hosted. They do not identify the human operator, malware family, botnet controller, or true country of origin. Cloud IPs are frequently abused as disposable infrastructure.
| IP | Country | City/Region | ISP / Org | ASN | Hosting | Attempts |
|---|---|---|---|---|---|---|
| 8.218.34.194 | Hong Kong | Hong Kong | Alibaba / Alibaba.com Singapore E-Commerce Private Limited | AS45102 Alibaba (US) Technology Co., Ltd. | Yes | 44 |
| 171.243.149.206 | Vietnam | Da Nang | Viettel / VIETEL | AS7552 Viettel Group | No | 14 |
| 34.48.5.154 | United States | Washington, D.C. | Google Cloud us-east4 | AS396982 Google LLC | Yes | 12 |
| 35.196.240.148 | United States | North Charleston, South Carolina | Google Cloud us-east1 | AS396982 Google LLC | Yes | 11 |
| 34.48.253.160 | United States | Washington, D.C. | Google Cloud us-east4 | AS396982 Google LLC | Yes | 10 |
| 176.65.139.151 | Netherlands | Eygelshoven | Offshore LC / Storm Industries | AS214472 Offshore LC | No per lookup | 2 |
Observed behavior
- Internet scanners identified an exposed SSH service.
- Attempts focused on root and common administrative/service usernames.
- The observed failures were password-authentication failures.
- Source addresses included both cloud-hosted systems and ISP networks.
- The username spread and short bursts look automated and opportunistic.
Representative log examples
Failed password for root from 35.196.240.148 port 55364 ssh2 Failed password for invalid user admin from 35.196.240.148 port 55242 ssh2 Failed password for invalid user support from 35.196.240.148 port 55278 ssh2 Failed password for invalid user vagrant from 8.218.34.194 port 33070 ssh2 Failed password for invalid user ftpuser from 116.110.213.45 port 46194 ssh2
High-level defensive takeaway
The main lesson is straightforward: any SSH service reachable from the public internet will attract automated password guessing. The safest posture is to avoid password-based SSH entirely, use key-based authentication, prevent direct root login, and restrict management access to trusted source networks where operationally possible.
These figures represent the currently available and parsed local log corpus. They should not be treated as a complete historical record of all SSH activity ever seen by the host.
Conclusion
The server saw routine internet SSH password guessing, with root receiving the majority of attempts. The source infrastructure spanned multiple geographies and providers, including Alibaba Cloud, Google Cloud, Viettel, and other networks. The pattern is consistent with commodity scanning rather than a targeted intrusion attempt.