Storing private keys on intermediary servers breaks the trust boundary of the jump path. A multi-user bastion is often accessible to more than one privileged operator, so any compromise of that host can expose keys used for later hops. That turns a controlled transit point into a high-value target and increases the blast radius of a single breach.
Why This Breaks the Trust Model
Storing private keys on an intermediary host changes that host from a transit control into a credential repository. The key no longer belongs only to the endpoint or operator that should use it, so the jump server becomes part of the trust boundary for every downstream target it can reach. In practice, that means host compromise, shared administrative access, backup exposure, or forensic access can all become routes to lateral movement.
It also weakens accountability. If several operators can reach the same intermediary, it becomes harder to prove which person or process used a key, whether the key was copied, and whether the same key was reused elsewhere. That is why long-lived private keys on shared systems are a common precursor to privilege spread rather than a safe shortcut for convenience. The strongest operational pattern is to keep keys off shared hosts entirely and prefer short-lived, scoped credentials where possible.
In practice, many teams discover the failure only after the bastion has already been treated as a benign admin convenience instead of a sensitive credential asset.
How the Failure Spreads in Real Environments
Once a private key sits on an intermediary server, several failure modes become possible at the same time. An attacker who gets shell access to that host can search for key material, copy it, and reuse it from a different location. A legitimate administrator with broad access can also exfiltrate or unintentionally expose it through config files, backups, process memory, or shared home directories. Even when the box is hardened, the blast radius is still larger than it should be because one compromise can unlock multiple later hops.
- Key theft becomes easier because the key is stored where multiple users, services, or scripts may read it.
- Rotation becomes harder because downstream systems may depend on the same key path or file location.
- Revocation becomes slower because you must first find every place the intermediary host can reach.
- Detection becomes noisier because legitimate jump activity and key abuse can look similar in logs.
The practical control issue is not just secrecy, it is scope. A shared intermediary turns one credential into an access broker, so compromise of the broker can expose every reachable target and make later movement look like routine administration. The moment the intermediary is persistent, multi-user, or backed up broadly, the design stops behaving like a narrow jump path and starts behaving like a secrets store.
These controls tend to break down when the same host is used for interactive admin access, automation, and file-based key storage because the operator, process, and credential boundaries collapse into one machine.
When the Usual Advice Needs Adjustment
Tighter SSH handling often increases operational overhead, so teams need to balance convenience against the cost of shared trust. In low-volume environments, a single jump host with carefully managed ephemeral access may be acceptable if keys are not persisted and access is tightly logged. In larger estates, though, the same pattern becomes brittle because one intermediary can accumulate too many trust relationships and too much historical credential residue.
There is no universal standard that says every intermediary must be eliminated. The real decision point is whether the host stores material secrets, whether those secrets are reusable outside the session, and whether compromise of the host would expose more than one intended path. If the answer to any of those is yes, the design is already carrying hidden privilege concentration.
One useful reference point is the broader NHI pattern that organisations struggle with long-lived credentials and insecure secret sharing, with only 19.6% of security professionals expressing strong confidence in their ability to securely manage non-human workload identities in The 2024 Non-Human Identity Security Report. That same design weakness shows up in SSH when private keys are copied onto shared systems instead of being kept bound to the originating trust boundary.
Risk and Threat Considerations
The main risk is credential compromise followed by lateral movement. A stored private key gives an attacker a reusable trust artifact, so one intermediary compromise can become access to multiple internal systems. The exposure is especially serious when the intermediary is shared, logged into by many operators, or reachable from less trusted admin workstations.
Failure mechanism: Attackers typically look for file-based keys, backup copies, config artifacts, and automation scripts on the intermediary host. Once the key is recovered, it can be reused from outside the original jump path unless additional controls such as source binding, short-lived credentials, or strong host attestation are in place.
Impact: The compromise can extend beyond the bastion itself, enabling privilege spread, unauthorized remote access, and delayed revocation across every downstream system that trusts that key.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secret Sprawl and Credential Exposure | Stored private keys on a shared hop create exactly the secret-sprawl exposure this question describes. |
| NHI-04 — Overprivilege and Excessive Standing Access | A reusable key on a bastion broadens blast radius and standing access to downstream systems. | |
| NHI-07 — Lack of Visibility and Auditability | Shared intermediary keys weaken attribution because multiple operators and processes can use them. | |
| Recommendation — Remove persistent private keys from intermediary hosts and replace them with short-lived access paths. Constrain each hop to the minimum downstream reach and eliminate reusable standing access. Log and attribute each key use so access remains traceable to a specific session or actor. | ||
| NIST CSF 2.0 | PR.AA-04 — Identity Management and Authentication | SSH key handling is an authentication and trust-boundary problem that CSF identity controls address. |
| Recommendation — Use managed authentication that avoids persisting reusable credentials on shared servers. | ||
| CIS Controls v8 | 6.3 — Credential and Access Review | Shared private keys require regular review, removal, and rotation to limit exposure. |
| 6.8 — Untrusted Credentials and Secret Storage | The core failure is storing sensitive credentials on a multi-user intermediary host. | |
| Recommendation — Review and remove stored SSH keys from intermediary systems on a defined schedule. Prohibit long-lived private key storage on shared admin hosts and use protected secret handling instead. | ||
| MITRE ATT&CK | T1552.004 — Unsecured Credentials: Private Keys | Recovered SSH private keys are a standard credential-access technique used for reuse and lateral movement. |
| Recommendation — Hunt for private key exposure on jump hosts and alert on unauthorized key discovery. | ||
Practitioner Guidance
What to prioritise: Treat any intermediary that stores private keys as a credential-handling system, not just a hop. If the host can reach production targets, the first priority is reducing reusable secret exposure, because compromise impact is driven by blast radius, not by how hardened the box looks.
What to verify: Confirm whether keys are persistent on disk, copied into automation, or shared across operators. Also verify whether rotation actually removes old access everywhere, because a key that can still authenticate after the jump host is rebuilt is still part of the trust chain.
Decision rule: If the intermediary must retain access material at all, limit it to short-lived, tightly scoped credentials with strong auditability. If the current design depends on a long-lived private key being present on the host, treat that as a higher-risk exception rather than a normal admin pattern.
Practitioner takeaway: The safest SSH design is the one that prevents the intermediary from becoming a reusable secret store, because once it does, the security boundary has already moved in the wrong direction.
