Abstract

SSH password authentication brute-forcing represents one of the most persistent and broadly distributed threats observed by Internet-facing infrastructure. This paper analyzes SSH password authentication attack patterns using data from the Dataplane.org sshpwauth and sshpwauthpairs signal feeds, covering credential distributions, source IP characteristics, temporal patterns, and operational countermeasures available to defenders.

Background

The SSH protocol (RFC 4253, RFC 4252) supports multiple authentication methods, of which password authentication, despite its security limitations, remains widely enabled on production infrastructure. Password authentication sends credentials over the encrypted SSH channel to the server for verification. This creates an observable signal: servers see authentication attempts from IPs that complete the SSH handshake and submit credentials.

Dataplane.org’s sshpwauth feed captures the source IPs of all hosts observed attempting SSH password authentication against sensor infrastructure. The sshpwauthpairs feed extends this to publish the username:password pairs themselves, providing visibility into the credential landscape being used in attacks.

Threat Landscape

Attack Volume and Distribution

SSH password authentication attacks are a continuous background phenomenon on the Internet. Dataplane.org sensors observe between 12,000 and 28,000 unique source IPs attempting password authentication on any given day, with periodic spikes during active botnet campaigns.

The geographic distribution of source IPs is heavily skewed toward:

  • Large hosting and cloud provider address space (AWS, Azure, Alibaba Cloud, DigitalOcean, Linode/Akamai, OVH, Hetzner)
  • Residential broadband in regions with high IoT device penetration
  • VPN/proxy exit nodes used to obfuscate origin

Credential Distribution

Analysis of the sshpwauthpairs data reveals consistent patterns in the credentials used:

Username distribution:

  • root accounts for approximately 40–55% of all authentication attempts
  • admin, ubuntu, pi, user, test, and oracle each represent significant fractions
  • Service account names (postgres, mysql, ftp, www-data) appear consistently
  • Cloud provider default usernames (ec2-user, centos, debian) are specifically targeted

Password characteristics:

  • Password lengths range from 1 to over 300 characters, with a median of approximately 8 characters
  • The most common passwords are dictionary words (password, 123456, admin, root, changeme), default device credentials (raspberry, admin123, 1234), and common cloud instance passwords
  • Credential pairs are often reused from data breaches; passwords observed in high-profile breach data appear in Dataplane.org sensor traffic within weeks of those breaches becoming publicly available

Credential refresh rate: Credential lists used by attacking infrastructure are updated frequently. Approximately 20–30% of passwords observed in any given month are new (not seen in the prior 30 days). This indicates active credential list maintenance by attack operators.

Temporal Patterns

SSH attack traffic is not uniformly distributed across time:

  • Botnet campaigns: Coordinated campaigns produce sharp spikes in unique source IP count lasting 24–96 hours, typically sourced from newly compromised hosts
  • Diurnal variation: Attack rates show weak diurnal patterns correlated with the geographic distribution of source IPs
  • Vulnerability-driven spikes: Significant increases in SSH attack activity correlate with public disclosure of new default credentials (e.g., new IoT device firmware defaults, cloud provider AMI defaults)

Botnet Behavior

A significant fraction of attacking IPs are themselves compromised hosts: IoT devices, poorly secured Linux servers, and embedded systems. These hosts:

  • Appear in the sshpwauth feed themselves (as victims of SSH compromise)
  • Have short active attack windows (hours to days before remediation or recompromise)
  • Are often concentrated in specific hosting providers or ASNs that have limited abuse remediation

Defensive Countermeasures

Immediate Mitigations

Disable password authentication: The highest-impact single change. Replace password authentication with public key authentication for all SSH access. This eliminates the attack surface for password brute-forcing entirely.

# In /etc/ssh/sshd_config:
PasswordAuthentication no
ChallengeResponseAuthentication no

Restrict SSH access by source IP: Limit SSH connections to known management IP ranges using firewall rules or /etc/hosts.deny. While not always practical, it dramatically reduces attack surface.

Change the default port: Moving SSH from port 22 to a high, non-standard port reduces automated attack volume by 90%+ in practice, though it provides no security against targeted attacks.

Rate Limiting and Fail2Ban

Implement connection rate limiting at the network level (iptables/nftables) and application level (Fail2Ban or sshguard). A typical effective configuration:

  • Block source IPs after 3–5 failed authentication attempts
  • Hold blocks for 24 hours minimum
  • Use Fail2Ban with recidive jail for repeat offenders (long-term blocks)

Two-Factor Authentication

TOTP-based 2FA (Google Authenticator, Duo) adds a second factor that defeats credential stuffing even if passwords are compromised. Most Linux SSH deployments can add TOTP via libpam-google-authenticator with minimal disruption.

Signal-Feed-Based Blocklisting

The Dataplane.org sshpwauth feed provides daily-refreshed lists of IPs actively attempting SSH password authentication. These can be consumed directly for:

  • Firewall blocklist population (iptables, pf, nftables)
  • SIEM alerting enrichment (flag authentications from known-bad IPs)
  • Threat intelligence platform ingestion (MISP, OpenCTI, TheHive)

Integration example (Linux iptables):

# Download and apply the SSH blocklist
wget -q https://dataplane.org/sshpwauth.txt -O /tmp/sshpwauth.txt

# Create ipset and populate
ipset create sshpwauth hash:ip
while read ip; do
  [[ "$ip" =~ ^#|^$ ]] && continue
  ipset add sshpwauth "$ip" 2>/dev/null
done < /tmp/sshpwauth.txt

# Block connections from listed IPs
iptables -I INPUT -m set --match-set sshpwauth src -p tcp --dport 22 -j DROP

Long-Term Posture

  • Patch regularly: Ensure OpenSSH is kept current to mitigate any vulnerabilities in the server itself
  • Audit authorized_keys: Regularly review authorized keys across all user accounts; remove stale entries
  • Monitor login success, not just failure: Credential stuffing success rates are low but non-zero; monitor for successful logins from unexpected source IPs
  • Consider certificate-based SSH: SSH certificates (via an internal CA) provide better scalability than per-host authorized_keys management for larger environments

Conclusion

SSH password authentication attacks are a reliable and continuous feature of the Internet threat landscape. The Dataplane.org sshpwauth and sshpwauthpairs feeds provide actionable, passively-collected intelligence about the sources and credentials in use. The most effective countermeasure is eliminating password authentication entirely; for environments where that is not possible, layered rate limiting, 2FA, and signal-feed-based blocking provide meaningful risk reduction.

Data used in this analysis was collected passively by Dataplane.org sensor infrastructure. No active probing was performed. Username:password pairs are published in aggregate statistical form; individual victim credentials are not published.