Exposed SSH and password-based brute forcing
The short version: An SSH service on the public internet that allows password authentication invites continuous brute-force and credential-stuffing attempts — and one weak, default, or reused password is all it takes.
What you need to know
SSH is meant to be reachable remotely, so exposure alone isn't the whole story — the risk is password authentication plus weak credentials. An SSH service that accepts passwords is a login an attacker can pound on indefinitely; an SSH service that requires keys is a fundamentally different, much harder target.
- How they find it — internet-wide scanning constantly catalogs open SSH services; a new one is discovered within hours.
- How they use it — automated brute force with default account/password pairs (root, admin, and friends) and low-and-slow spraying with common and previously-breached credentials.
- What it leads to — a working credential yields shell access to the host and a base to move and escalate from. Because SSH so often fronts servers and infrastructure, that access tends to be valuable.
How serious we see it
Moderate — by default, with honest upside risk. SSH is designed to be exposed and can be exposed safely, so we don't cry "Critical" on sight. An SSH service that requires key-based authentication and disallows password login is a well-defended door. But if password authentication is enabled and any account uses a weak, default, or reused password, this quietly becomes High — a direct, unauthenticated path to shell access. The reassuring part: the strongest fix is a configuration change you control, not a vendor patch.
What to do
- Require key-based authentication — disable password authentication (
PasswordAuthentication no) wherever possible; this is the single highest-value control. - Disable direct root login — and enforce strong, unique passwords anywhere passwords must remain.
- Restrict exposure — limit SSH to trusted IP addresses or place it behind a VPN.
- Limit and monitor failed logins — rate-limit attempts (e.g. with fail2ban), enforce lockouts, and alert on brute-force patterns.
- Confirm your exposure first — verify which SSH services are internet-facing and whether they still accept passwords.
How BreachRisk sees it
BreachRisk discovers internet-facing SSH services in your external footprint, and then, where authorized, goes a step further than a scanner: it safely attempts a bounded, rate-limited authentication check using default, exposed (breach-corpus), and common credentials, within strict non-disruptive limits rather than a brute-force flood. Where the service correctly requires key-based authentication, that shows up as the safe, well-configured result it is. That's the honest difference between detecting an SSH service and demonstrating whether its credentials actually hold.