SSH-Snake is a self-propagating, fileless Bash script that recursively discovers SSH private keys and traverses hosts to map network trust relationships, intended for authorized penetration tests and infrastructure audits.
| Tool | MegaManSec/SSH-Snake — fileless, self-replicating Bash script for recursive SSH network traversal |
| Category | post-exploitation / network discovery tooling |
| Primary Use | Automating the discovery of SSH private keys and reachable user@host destinations to map credential trust chains during authorized assessments |
| Safe Use | Use exclusively within authorized penetration tests, owned lab environments, or internal infrastructure audits to understand SSH key sprawl and lateral movement paths |
| Telemetry Note | The README states the script leaves no files behind; its footprint appears in the process tree and as a high volume of invalid SSH authentication attempts, which defenders can detect via auth log monitoring and failed-login alerting |
SSH-Snake occupies an unusual niche in offensive tooling: it is a worm-like traversal utility written entirely in Bash, released under GPL-3.0 and authored by Joshua Rogers. Its stated objective is not exploitation of a vulnerability but mapping — given a foothold on one system, it answers the question of how far an adversary (or an auditor) could move using nothing but SSH private keys already present on that system. The repository frames this as automating a task that would otherwise require a human operator to manually hop between hosts, collecting keys and testing destinations one at a time. With roughly 2,300 stars and a pure Shell codebase, it has clearly resonated with the pentesting community as a reference implementation of credential-based lateral movement.
The core loop is four steps, executed recursively. The script locates SSH private keys on the current system, enumerates candidate destinations in user@host form where those keys might be accepted, attempts connections using every discovered key, and repeats the process on each successfully reached system. The README is explicit that the tool is self-replicating and self-propagating — in effect a computer worm — but its purpose within an authorized engagement is to produce a graph of trust relationships rather than to deliver a payload. It emulates, in the author's words, what a human adversary would do to discover keys and the systems that accept them.
Architecturally, the most interesting design decision is filelessness. SSH-Snake never writes itself to disk on target systems; it is passed to remote bash via stdin and command-line arguments over SSH. The README explains that the script is actually a Quine — it reproduces its own source — and because bash writes a temporary file for here-documents larger than 65535 bytes, the repository ships Snake.nocomments.sh, a stripped build with comments and whitespace removed specifically so that temporary file is never created. That level of attention to operational detail tells you the author thought carefully about leaving minimal forensic evidence; the README candidly notes the only remaining traces are the process tree and the inevitable flood of invalid SSH attempts.
Dependency management is similarly pragmatic. The script relies on bash, ssh, coreutils, awk, uniq, sort, grep, tr, find, and cat, plus either getent or dscacheutil — a set almost universally present on Linux and macOS. Optional tools like sudo, hostname, ip, timeout, arp, ifconfig, ipconfig, and xargs enhance capability when available, and the script degrades gracefully, alerting the user when a hop cannot continue and backtracking to the previous system. This makes it robust across heterogeneous estates, which is exactly the environment where manual key-trust mapping collapses under its own weight.
Key discovery goes well beyond scanning ~/.ssh. The feature list includes extracting private key references from .bash_history entries, checking commonly used files and folders, and a plug-and-play modular system for both key discovery and host enumeration. Host detection draws from IP ranges, last logins, known_hosts files, and SSH config files. Each discovery strategy — except the mandatory find_ssh_keys — can be toggled in SETTINGS.md, letting an operator trade thoroughness against scan time depending on the engagement window.
Recursion control is handled with a depth-first traversal strategy: once connected to a system, the script pushes deeper before backtracking, and it tracks which systems have been scanned or are currently being scanned to avoid infinite loops. The README illustrates this with a A->B->C chain that can still discover C->A without regressing into an endless cycle. The name itself comes from the snake-like appearance of the output as the script slithers up and down the network — with the noted improvement over the game that it survives biting its own tail.
The output is a raw log mixing discovered keys, destinations, and errors, documented in OUTPUT.md with a worked example in example-output.log. What elevates the tool from a traversal script to an analysis platform is the visualization pipeline described in GRAPHICS.md: the log can be rendered into graphs showing systems as nodes and key-based reachability as edges, including self-connections and bi-directional trust. Three companion Python utilities extend this — forward-lookup-host.py for everything reachable from a source, reverse-lookup-host.py for everything that can reach a destination, and shortest-path-create-chain.py for the shortest hop chain between two points. The reverse-lookup tool in particular is arguably the most defensively valuable artifact in the repository: it answers "who can get to this crown-jewel host?" directly.
One capability deserves explicit caution: the README lists exfiltration of discovered private keys as script output among its features, and notes that printing keys can be disabled by commenting out a specific line in Snake.sh. For defensive or audit use, that toggle matters — a sysadmin assessing their own infrastructure generally wants the trust graph, not the key material itself. This is a good example of the dual-use posture an operator should consciously manage.
Running it is deliberately trivial, and the README offers the canonical pipe-to-bash pattern: curl https://raw.githubusercontent.com/MegaManSec/SSH-Snake/main/Snake.nocomments.sh | bash. As a matter of professional hygiene, reviewing the stripped script before execution — or fetching and auditing it first — is the responsible variant of that one-liner, and the commented Snake.sh exists precisely for readability.
The limitations section is refreshingly honest: IPv4 only, an assumption that SSH runs on port 22, heavy reliance on GNU coreutils with undetermined portability to BusyBox-style environments, and no attempt to look for SSH agent sockets. These constraints define where the tool fits — classic Linux datacenter and development estates rather than hardened or exotic environments.
From a defensive perspective, SSH-Snake is best understood as a stress test for key hygiene. Its telemetry signature — clusters of failed SSH authentications across many hosts from unexpected sources — is exactly what centralized auth log analysis and anomaly-based failed-login alerting should catch. Its existence is a strong argument for hardware-backed keys, per-host certificates, and periodic audits of where long-lived private keys are actually accepted, which is precisely the visibility the tool's graph output provides when run by authorized teams against their own infrastructure.
For authorized professionals, SSH-Snake condenses days of manual lateral-movement analysis into a single automated pass, and its companion lookup and visualization tools turn raw traversal data into actionable network graphs. Whether used from the red side to demonstrate blast radius or the blue side to inventory key-based trust, it is one of the clearest public articulations of how SSH key sprawl silently shapes an enterprise's real attack surface.
MegaManSec/SSH-Snake.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.