# SSH Auth Attack Surface Discovery

- **URL:** https://hackindex.io/services/ssh/exploitation/ssh-auth-attack-surface-discovery
- **Path:** SSH > Exploitation
- **Up:** [Exploitation](https://hackindex.io/services/ssh/exploitation.md)
- **Published:** 2026-01-03
- **Updated:** 2026-01-03

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.

```bash
ssh -vvv -p $PORT -o BatchMode=yes -o PreferredAuthentications=password -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null $USERNAME@$TARGET_IP exit
```

If password auth is disabled, you’ll usually see it missing from the server’s offer line:

```bash
debug1: Authentications that can continue: publickey,keyboard-interactive
```

Now force publickey and see if it’s offered for this user:

```bash
ssh -vvv -p $PORT -o BatchMode=yes -o PreferredAuthentications=none -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null root@$TARGET_IP exit
```

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:

```bash
ssh -p $PORT invaliduser@$TARGET_IP
```

If you want to compare behavior at scale with minimal pressure:

```bash
hydra -L users.txt -p invalid ssh://$TARGET_IP -t 1
```

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.

## SSH 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.

```bash
hydra -l $USERNAME -P small.txt ssh://$TARGET_IP -t 1 -W 5
```

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 page](https://man.openbsd.org/ssh) - BatchMode, verbosity, and auth selection behavior.
- [THC Hydra](https://github.com/vanhauser-thc/thc-hydra) - SSH module and concurrency tuning for controlled auth probing.
