SSHamble looks for the SSH exposures you did not configure

A research tool with an explicit warning

SSHamble is described as a research tool for SSH implementations, and the README says plainly that this project is a work-in-progress and likely to change quickly. The attack surface it covers is listed in five categories: interesting attacks against authentication, post-session authentication attacks, pre-authentication state transitions, authentication timing analysis, and post-session enumeration. That list is the tool's scope statement, and it is a scope statement about SSH servers rather than about networks in general, which is what makes it a research instrument rather than a general scanner. The project site is SSHamble.com and the team is reachable at a runZero research address. The licence is a custom one that GitHub cannot classify, with the terms in the LICENSE file at the repository root.

Scan and analyze are separate steps

The workflow is two commands, and separating them is the practical design choice. A scan enumerates a set of targets for SSH capabilities and exposures and writes JSON lines, and an analyze command takes a scan output file and buckets the results into a directory:

$ ./sshamble scan -o results.jsonl 192.168.0.0/24
$ ./sshamble analyze -o results-directory results.jsonl

There are three subcommands in total, and the third is for the blocklist cache. `scan` enumerates a set of targets, `analyze` analyses a scan JSON output file and buckets results, and `badkeys-update` updates the badkeys.info blocklist cache. The separation means you can scan a large range once, then re-run the analysis with different bucketing without touching the network again, and it means the scan output, which is the sensitive part, can be stored and handled separately from the report you share.

The check list is the real specification

The default check list is long and it is the best documentation of what the tool actually does, because each name maps to a specific behaviour of an SSH implementation. The defaults include the badkeys blocklist check, GSSAPI any, several keyboard-interactive checks for empty, null and user responses, password checks for any and for the empty, null and user variants, password change checks, public key checks including a bulk-half hunt and a user variant, and a group of skip-authentication checks, including skip-auth, skip-auth-method-empty, skip-auth-method-null, skip-auth-none, skip-auth-pubkeyany, skip-auth-success and skip-ssh-userauth. There are also vulnerability checks that are specific to software rather than to the protocol, covering environment exposure in generic, Gogs, Ruckus password escape, SoftServe and TCP forwarding. The `--categories` flag narrows the run to a set such as bypass, gssapi, hostkey, keyboard, password, pubkey, userenum and vuln, and the `--checks` flag lets you add the non-default ones.

The tuning flags are where the care goes

The scan flags are where an operator has to make decisions, and several of them are about not being rude. `--max-connections` caps concurrent connections at 5000 by default, and `--timeout` sets how many seconds to wait for a target to respond, at 5 by default. `--retries` sets the retry count for subsequent failed connections after an initial success, at 2. `--pubkey-bulk-limit` is the number of public key half-auths to test for max attempts, at 10, and `--pubkey-hunt-conn-limit` is the number of public keys to test in each connection, at 250000. The user enumeration knobs are `--userenum-max-per-session-count` at 1023 authentication attempts per session and `--userenum-test-count` at 2500 tests. There is also `--skip-versions`, a regular expression of SSH versions to skip, with the example given as one matching OpenSSH or Dropbear, which is a blunt instrument for excluding implementations you already know are fine.

The client version string is a deliberate choice

One flag deserves attention because it changes what the target sees. `--client-version` sets the client version string to send, defaulting to `OpenSSH_9.8p1`. Since the SSH banner is one of the first things a server processes, and servers have historically behaved differently depending on the version they are told, being able to send an arbitrary string is how a researcher compares implementations against each other rather than only against the current default. The same reasoning applies to `--session-poke`, a byte sequence sent to sessions to elicit further responses, defaulting to a newline and carriage return sequence, which is a way of checking whether a server discloses anything when a session is opened but not used. The interactive flags, `--interact` and `--interact-auto`, control whether a shell is opened and which commands to run in it.

Building it and the badkeys cache

Binaries are available from the releases page, and there is a macOS caveat: you will likely have to disable Gatekeeper for the binary with `sudo xattr -rd com.apple.quarantine ./sshamble`, and the README adds that this is not an invitation to violate your asset owner's security policy. To build from source you need Go 1.27.1 or newer, and on macOS you may hit runtime errors unless you disable CGO before building with `export CGO_ENABLED=0`. The ordinary path is `go install github.com/runZeroInc/sshamble@latest`, and the from-source path is a clone, a `go build -o sshamble` and a `./sshamble -h`. To enable badkeys support you run `sshamble badkeys-update` first, and the README shows the source build with a `go generate ./...` step in between, which is how the blocklist data is brought into the binary.

Editorial conclusion

Adopt SSHamble if you run an SSH estate and want to find servers behaving in ways their configuration did not intend, since the checks cover authentication edge cases and pre-authentication behaviour that a normal audit misses. Do not point it at infrastructure you are not authorised to test, and read the interaction flags carefully before a wide scan, since the tool opens real sessions and can attempt authentication. Verify first that the version you use supports the checks you need, that your rate limits are appropriate for the target range, and that the JSON output stays somewhere you control, since the results describe the weaknesses of your estate.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. runZeroInc/sshamble on GitHub