The Harvest: When the Backdoor Is the Victim's Own Key

The Skeleton Key — Part 4

Classification: HIGH · Confidence: HIGH (first-party command capture); CALIBRATED on downstream impact

Two operators in this thread have fought over the same file. One plants a key by deleting everything else; the other plants a key and makes it impossible to delete. Both treat ~/.ssh/authorized_keys as a way in — a door to install and hold. This letter is about an operator who looked at the same directory and saw the opposite thing. It plants nothing. It installs no backdoor, locks no file, leaves no key of its own. It reads. And what it reads is the way out — the victim's own keys, and the map of everywhere those keys can go.

The command, captured once, on 2026-05-11:

echo "===SSHKEYS===";
find /home /root -name "id_rsa" -o -name "id_ed25519" -o -name "id_dsa"
  -o -name "*.pub" -o -name "known_hosts" -o -name "authorized_keys" 2>/dev/null;
echo "===SSHKEYS2===";
find /home /root -path "*/.ssh/*" 2>/dev/null

There is no persistence here, no miner, no lock. There is a search, wrapped in two delimiter strings — ===SSHKEYS=== and ===SSHKEYS2=== — whose only purpose is to let an automated collector on the other end find and parse the results. This is not a human browsing. It is a harvester, and what it harvests is the material that turns one cracked machine into a foothold on every machine that machine can reach.

What the search is reaching for

Each name in the find is a different piece of the victim's trust, and it is worth taking them in order of value.

The private keys — id_rsa, id_ed25519, id_dsa — are the prize. A private key is the victim's identity to other machines: whatever servers accept that key, its holder can log into as the victim, with no password and no further exploitation. Steal id_rsa, and every host on which the victim's corresponding public key sits in an authorized_keys file becomes reachable — not by attacking it, but by authenticating to it, legitimately, as the person the key belongs to. This is the crown jewel, and it is why the search names all three key algorithms: it does not know which the victim used, so it asks for every kind.

The known_hosts file is the map. Every time a user connects to a server over SSH, that server's fingerprint is recorded in known_hosts, which means the file is a list of everywhere the victim habitually goes. To an attacker holding the victim's private key, known_hosts is a target list — not "where might this key work?" but "here are the exact hosts this person actually connects to." The private key is the master key; known_hosts is the ring of addresses it was cut for.

The *.pub files reveal which public keys exist, letting the harvester match identities and fingerprints. And authorized_keys — the very file the plant-and-lock operators fight over — is read here for the reverse of its usual meaning: not to install access, but to inventory it, to learn who else can reach this box and by which keys. The second find, sweeping the entire .ssh directory, catches anything the named search missed — config files naming internal hostnames, agent sockets, additional keys. The harvest wants the whole directory, because the whole directory is a dossier on the victim's place in a network of trust.

The second sweep catches the best map of all

The command runs two searches, and the second — find /home /root -path "*/.ssh/*" — is not redundant. It sweeps the entire .ssh directory rather than the named files, and the most valuable thing it catches that the first search does not is ~/.ssh/config.

An SSH config file is, for a real user, a convenience: it defines short aliases for the hosts they connect to, records usernames, jump hosts, key files, and forwarding settings. For a harvester, it is a better map than known_hosts by a wide margin. Where known_hosts lists fingerprints — and, when hashed, only anonymized ones — config lists hosts by the names and roles the user gave them: Host prod-db, Host bastion, Host internal-git, each with its hostname, its username, and often the exact private key to use. It is not a list of fingerprints; it is a labeled diagram of the victim's network, annotated with which key opens which door and how to route to it through which jump host. A user's own config frequently hands an attacker the entire topology and the credential-to-target mapping in one file, pre-organized. The second find exists to make sure that file, and the agent sockets and secondary keys that also live loose in .ssh, are not missed. The harvester does not just want the keys; it wants the user's own documentation of what the keys are for.

There is an adjacent vector the sweep's logic points at, even if this capture does not exploit it: the SSH agent. A running ssh-agent holds decrypted keys in memory and exposes a socket, and access to that socket — or to a session where agent forwarding is enabled — lets an attacker authenticate with the victim's keys without ever reading the key file, defeating even passphrase protection for as long as the agent lives. An operator who enumerates .ssh this thoroughly is one step from the agent, and the two together — the on-disk keys and the in-memory agent — are the complete picture of a victim's outbound trust. The harvest reads the disk; the agent is the same theft, one layer up, against the keys too well-protected to steal at rest.

The directory that faces both ways

The deep point this operator exposes is that ~/.ssh is a two-faced thing, and the corpus's three key operators split cleanly along its two faces.

authorized_keys faces inward: it decides who may enter this machine. That is the face the Outlaw eviction and the immutable lock exploit — they write to it, fight over it, freeze it, all to control who comes in. But id_rsa and known_hosts face outward: they are this machine's credentials and map for reaching other machines. That is the face the harvester exploits. The same small directory is simultaneously a door into the host and a keyring-plus-map out of it, and an attacker's intent determines which face they see. The planters saw a door and installed a lock. The harvester saw a keyring and took it.

This is why the harvest is a fundamentally different and, in the trust it abuses, more dangerous act than planting. Planting adds a new credential — foreign, revocable, detectable as a key that does not belong. Harvesting steals an existing credential — legitimate, trusted, indistinguishable from the real user when it is used. The planter leaves something behind that a defender can find and remove. The harvester takes something away that the defender may never know is gone, and then uses it to become the victim on every machine that trusts them.

The supply chain of trust

SSH keys do not describe a single machine; they describe a graph. A developer's laptop holds a key authorized on the build server; the build server holds a key authorized on production; production holds a key authorized on the database. Each edge is a trust relationship, encoded as a private key on one side and an authorized_keys entry on the other, and the whole fabric of who-can-reach-what in a modern infrastructure is written, in plaintext keys, into a scatter of ~/.ssh directories.

The harvest walks that graph. Crack the weakest host — the developer's laptop, the forgotten jump box, the one machine with a guessable password — and harvest its ~/.ssh, and you gain not just that host but its edges: the private keys that reach the next tier, and the known_hosts map that tells you where the next tier is. Repeat at the next host, and the next. Each hop's .ssh directory is simultaneously loot (keys to steal) and map (hosts to steal them for), and a single weak SSH endpoint becomes the entry point to everything it, transitively, is trusted to reach. This is how breaches that begin at one negligible machine end at the crown-jewel database three hops away — not through a chain of exploits, but through a chain of trusts, each one harvested from the last. The keys are the lateral movement. The command captured here is the first step of exactly that walk: enumerate this host's edges, so the graph can be traversed.

That the corpus caught it running only once, from a single source, on a single day, fits the pattern. This is not the hundred-handed flood of a mass botnet planting the same key everywhere. It is one deliberate act against one host — someone who cracked this specific box and immediately asked the question a mass miner never asks: not "how do I stay here?" but "where can this host take me?" The harvest is targeted by nature, because its value is not the host it runs on but the hosts that host can reach.

Why the harvest resists both detection and cure

The harvested key is the hardest backdoor in this thread to defend against, precisely because it is not a backdoor at all — it is the front door, used by the rightful key.

Detection fails because the subsequent access is legitimate. When the attacker later logs into production with the developer's stolen key, there is no exploit, no brute force, no foreign key in authorized_keys, no anomalous binary. There is a valid key authentication from the developer's own credential — the same event that happens a hundred times a day for real. The malicious login is a needle in a haystack of identical legitimate needles, distinguishable, if at all, only by source address or timing, never by the credential itself. The planters leave a foreign key a scan can find; the harvester leaves nothing on the downstream hosts at all, because it arrives as the trusted user.

Cure fails because the credential is shared, not added. Removing a planted key restores the machine. But a harvested key cannot be "removed" from the attacker — it has been copied, and the only true remediation is to rotate the victim's real credentials everywhere they are trusted: revoke the stolen key on every host that accepts it, regenerate it, and re-authorize the new one across the entire graph. On a real infrastructure, that is a painful, sprawling operation, and it must be done for every key the harvest could have touched, because the defender usually cannot know which keys were actually exfiltrated versus merely enumerated. The plant costs the defender a sed command. The harvest costs them a key-rotation project across their fleet.

One harvest in a corpus of miners

Step back from the command to where it sits in the whole census, because its rarity is a finding in itself. The honeypot's corpus is overwhelmingly host-oriented: brute-force in, plant persistence, mine the CPU, move to the next box. Every operator examined so far — the toolkit, RedTail, the staged sweeps, the Outlaw key, the immutable lock — is after the machine it landed on, for its cycles or its bandwidth or its place in a botnet. The harvest is the one act in the corpus oriented not at the host but at the network the host belongs to. It does not care about this machine's CPU. It cares about this machine's edges.

That difference is the difference between commodity crime and targeted intrusion, and it is legible in a single command. A miner asks how do I stay and earn here? A harvester asks where does this host let me go? — which is the question of an operator who is not counting cracked boxes but traversing toward a specific objective, using each box as a stepping stone rather than a destination. The presence of exactly one such command in a sea of plant-and-mine activity is exactly what you would expect if the honeypot's population is what it appears to be: a large commodity botnet economy with a thin thread of something more purposeful running through it, mostly invisible because targeted operators do not spray, and detectable here only because this one happened to run its enumeration on a sensor that records everything.

It is worth resisting the urge to over-read a single capture — one command is one command — but it is equally worth not under-reading it. In a corpus where the dominant behavior is smash-and-grab, the rare act that reads the victim's trust graph rather than stealing its cycles is the one that would matter most on a real network, and it is precisely the one a summary optimized for volume would never surface. The miners are the noise. The single harvest is the signal that someone, at least once, was after the map.

Defense: make the keys worthless to steal

The mitigations for the harvest are different in kind from those for the planters, because the goal is not to keep the attacker out of the file but to make what they take from it useless.

The single most effective and most neglected control is the passphrase. A private key encrypted with a strong passphrase is, when stolen, an inert blob — the harvester gets the file but not the ability to use it, because authentication requires decrypting the key, which requires the passphrase the file does not contain. An unencrypted id_rsa, the default that countless users accept, is a credential in the clear; an encrypted one is a locked box the harvest cannot open. Most stolen keys are usable only because they were never passphrase-protected.

Beyond that: short-lived certificates. An infrastructure that issues SSH certificates valid for hours rather than static keys valid forever turns a harvested credential from a permanent asset into one that expires before it can be walked very far — the single change that most degrades the harvest's whole value proposition. Hash known_hosts (HashKnownHosts yes), so the map the harvester reads is a list of fingerprints without hostnames, denying the attacker the target list even when they get the file. And for detection, the command itself is a near-pure signal: no administrator greps /home and /root for id_rsa and known_hosts in a single sweep, so a find enumerating private keys across user directories is an almost false-positive-free tripwire — one that fires at the harvest's reconnaissance step, before the stolen keys have been used to go anywhere. The planters are caught by watching authorized_keys for what gets written. The harvester is caught by watching the whole .ssh directory for what gets read.

The markers are a machine's handwriting

One detail fixes the character of the operator beyond doubt: the ===SSHKEYS=== and ===SSHKEYS2=== delimiters. They serve no purpose for a human reading a terminal — a person scrolling output does not need banner strings to find the find results. They exist only so that code on the other end can locate the block between the markers and parse it: split on ===SSHKEYS===, take what follows, feed it to whatever consumes harvested keys next. Structured delimiters bracketing command output are the handwriting of an automated post-exploitation routine, the same convention frameworks use to carve one blob of shell output into labeled fields. This is not someone typing find and reading the answer. It is a program that logged in, ran a canned enumeration, and shipped the delimited result to a collector — which is consistent with everything else about the command: the exhaustive multi-algorithm key search, the two-pass sweep, the single clean execution. A human improvises and re-runs; a tool fires once, cleanly, with markers so its output parses. The harvest wears a machine's handwriting, and the handwriting says this key-collection step is one stage of a larger automated pipeline the sensor caught a single frame of.

Bounds and limits

DOCUMENTED, first-party: the exact enumeration command, captured once on 2026-05-11 from a single source, searching /home and /root for id_rsa, id_ed25519, id_dsa, *.pub, known_hosts, and authorized_keys, delimited by machine-parseable ===SSHKEYS=== markers, followed by a full .ssh directory sweep.

INFERRED, high confidence: that this is an automated harvesting step (the delimiter markers exist only to let a collector parse the output) whose purpose is credential theft for lateral movement (the specific set of files targeted — private keys plus known_hosts — is precisely the material required to authenticate as the victim to other hosts and to know which hosts those are). INFERRED, moderate confidence: that the operation is targeted rather than mass (a single execution against one host, in contrast to the corpus's hundred-handed planters).

BOUNDED — and this bound matters: the captured command enumerates the keys; it lists their paths. A harvest completes only when the key contents are read and exfiltrated, which would be a follow-on cat/read step not present in this single capture — so what is documented here is the reconnaissance stage of a harvest, and the theft itself is the demonstrated capability and intent of the command, reconstructed from what it searches for, not an observed exfiltration. On the honeypot there were no real keys to steal, so the downstream lateral-movement scenario is the command's demonstrated capability against a real host, not a breach this sensor witnessed. The impact of a harvest on any given real host depends entirely on whether that host's keys were passphrase-protected — the one variable that separates a catastrophic trust-graph traversal from a directory full of useless encrypted blobs.

None of these bounds change the shape of the finding. The corpus's SSH-key economy has three verbs, not one. Two operators plant and lock, using ~/.ssh as a door to hold. This one harvests, using the same directory as a keyring and a map to leave by — turning the victim's own trusted credentials into the means of reaching everything the victim could reach. The skeleton key opens one machine's door. The harvest steals the keys to all the doors the machine already had, and walks out through them as the person who owns them.

This closes The Skeleton Key. The series began with a single famous key of reach without an owner, and resolved it to one owner behind a hundred hands; then read the command and found the reach is taken by eviction; then found a rival who makes its key immutable; and ends here, with the operator who plants no key at all, and instead steals the ones the victim already trusted. One directory, three verbs, two directions: the way in, held two ways, and the way out, taken once — and the way out is the one that turns a single weak machine into a map of everything behind it.