SSH Auth Attack Surface Discovery
Profile SSH authentication behavior and defenses so your credential work is targeted and doesn’t faceplant into lockouts.
Password auth vs publickey branches
You want a quick answer to “is password auth even on” without turning it into a credential attempt. Force an auth type, keep it non-interactive, and read the server’s offers.
If password auth is disabled, you’ll usually see it missing from the server’s offer line:
Now force publickey and see if it’s offered for this user:
What you’ll typically observe:
Immediate “Permission denied” with a short list of offered methods often means root is restricted.
The same method list as normal users suggests root is reachable under the same auth policy.
Username signal via auth behavior
SSH isn’t a clean username enumeration protocol. Still, some stacks leak behavior differences. Use it as a signal, not a truth source.
Quick sanity check:
If you want to compare behavior at scale with minimal pressure:
If valid users consistently fail differently (timing, error strings, disconnect behavior), you can use that to prioritize usernames. If the behavior is inconsistent, drop it and move on.
Lockout and rate limiting detection
Before spraying or brute forcing, test how quickly the target gets angry. One user and a small password set is enough.
You’re watching for:
delays increasing after failures
connection resets after N attempts
new connections being refused for a cooldown window
the service becoming flaky under load
If you see these signals, tune your exploitation work down hard or stop if ROE requires it.
References
-
ssh(1) manual pageman.openbsd.org/ssh (opens in new tab)
BatchMode, verbosity, and auth selection behavior.
-
SSH module and concurrency tuning for controlled auth probing.
Was this helpful?
Your feedback helps improve this page.