My IP Help

SSH Scanning

Automated scanning of the public internet for servers with open SSH (port 22), followed by brute-force login attempts against any that respond.

Last updated:

What is SSH scanning?

SSH scanning is the constant background-noise activity of attackers probing every routable IPv4 address for an open SSH service on port 22, and attempting to log in once a responsive server is found. Any public-internet SSH server on its default port receives thousands to hundreds of thousands of login attempts per day from this traffic, regardless of how obscure or small the server is. Most of the attempts come from botnets of previously-compromised servers running the same scanner script.

What scanners try

A typical SSH-scanning campaign runs through a dictionary of common usernames (root, admin, ubuntu, ec2-user, oracle, postgres, git, pi) paired with common passwords and default vendor credentials. More patient campaigns layer in credential stuffing — trying leaked username:password pairs against SSH in the hope a sysadmin reuses a personal password. Successful logins are immediately followed by malware drop, crypto-mining, or enrollment of the new host into the scanning botnet.

How to harden SSH against scanning

Standard best practice cuts the attack surface to near zero:

  • Disable password authentication — require SSH keys only. Key-based auth cannot be brute-forced in human timescales.
  • Disable root login — force attackers to guess both a username and a password.
  • Move SSH off port 22 — reduces noise dramatically, though is not security on its own.
  • Use a firewall or fail2ban to block IPs after a few failed attempts.
  • Allowlist management IPs if you know them — typical for cloud infrastructure management.

Checking the source IPs of failed attempts against an IP abuse report checker confirms they belong to the known SSH-scanning swarm.

Frequently Asked Questions

In nearly every jurisdiction, yes — unauthorized login attempts against a system you do not own violate computer-misuse laws (US Computer Fraud and Abuse Act, UK Computer Misuse Act 1990, EU Directive 2013/40/EU). Pure port-state scanning (SYN, no login) sits in a grayer area in some jurisdictions, but the moment a credential is submitted, the activity is criminal. Enforcement is rare for individual scans because attribution is hard and damages are minimal, but coordinated campaigns and successful intrusions are prosecuted.
Check `/var/log/auth.log` (Debian/Ubuntu) or `/var/log/secure` (RHEL/CentOS) for entries like "Failed password for invalid user X from Y". A new server on a public IP will show thousands per day. Tools like `lastb` show recent failed logins, `ss -tnp` shows active connections to port 22, and journalctl with `--unit=ssh.service` gives a structured view. Most cloud providers (AWS, GCP, Azure) also surface failed-login metrics in their monitoring consoles.
It dramatically reduces the volume of automated noise — most botnets only probe port 22 — but it is not real security. A determined attacker can scan all 65,535 ports in under an hour with `masscan` or `zmap`. Port-changing is useful for keeping your logs readable and for slowing opportunistic attacks, but should always be paired with key-only auth, no root login, and fail2ban or equivalent.
Fail2ban watches your SSH log file for failed login patterns and automatically adds offending IP addresses to your firewall's block list (typically iptables or nftables) after a configurable number of failures. Default settings ban an IP for 10 minutes after 5 failed attempts in 10 minutes. It does not prevent the first few attempts but caps how long any single IP can hammer the server, effectively neutralizing dictionary attacks while tolerating occasional human mistakes.
In any practical sense, yes. A 2048-bit RSA key or a 256-bit Ed25519 key has roughly 2^112 to 2^128 effective security strength — far beyond what any computer (classical or foreseeable quantum) could brute-force. The realistic threats to SSH key auth are stolen private keys (from a compromised developer machine), passphrase-less keys on shared systems, and misconfigured `authorized_keys` files. The cryptography itself is not the weak link.
Back to glossary