SSH bastion key forwarding shows where access control still breaks

At a glance

What this is: This tutorial explains SSH key forwarding through a bastion host and shows how the access path can be simplified without storing private keys on the server.

Why it matters: It matters because bastion access is still identity governance, and the same assumptions about privilege scope, key handling, and session trust show up in NHI, autonomous, and human access programmes.

By the numbers:

• NHIs outnumber human identities by 25x to 50x in modern enterprises.
• Only 5.7% of organisations have full visibility into their service accounts.
• 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read StrongDM's tutorial on SSH bastion key forwarding

Context

SSH bastion access is a control-plane problem as much as a remote-login problem. The article shows how key forwarding lets an operator reach an internal host through a jump server without copying a private key to either server, which reduces some exposure but does not change the underlying trust chain.

For identity teams, the relevant question is not whether SSH can be made smoother, but whether the access path remains auditable, revocable, and constrained enough for governance. That is the same issue that appears in service account access, workload credentials, and privileged human sessions when the session boundary becomes the control boundary.

Key questions

Q: How should security teams govern SSH bastion access in privileged environments?

A: Treat bastion access as a privileged session path that needs explicit approval, logging, and revocation. Restrict who can use agent forwarding, limit which internal hosts are reachable, and ensure each hop is tied to an accountable operator. If the bastion cannot support those controls, it is expanding risk rather than reducing it.

Q: When does SSH agent forwarding create more risk than it reduces?

A: It creates more risk when the bastion or downstream host is broadly trusted, when multiple targets are reachable from the same session, or when audit trails do not show the full chain. In those cases, forwarding extends credential usability beyond the operator’s immediate endpoint and weakens the integrity of access boundaries.

Q: What breaks when bastion access is not logged end to end?

A: Revocation and forensics both fail. If teams cannot see which operator reached which host through which jump server, they cannot prove scope, reconstruct misuse, or confidently retire access after a change. Bastion logging needs to connect the initiating identity, the relay host, and the final destination.

Q: How do organisations reduce SSH key exposure without weakening admin access?

A: Keep private keys on the operator endpoint, limit forwarding to approved workflows, and pair it with strong bastion restrictions and detailed session logging. The goal is not simply to move the key, but to prevent uncontrolled reuse of the delegated access path across internal systems.

Technical breakdown

SSH key forwarding through a bastion host

SSH agent forwarding lets a user keep the private key on the local machine while the bastion host receives a forwarded authentication request. The bastion can then open a second SSH session to the internal host without storing the key itself. That improves convenience and reduces direct key placement on the server, but it also extends trust from the endpoint to the jump host and to every session path in between. The key never becomes harmless simply because it is not written to disk on the bastion.

Practical implication: treat the bastion as a privileged transit point and restrict which hosts can accept forwarded sessions.

Bastion hosts as privileged access choke points

A bastion host is a controlled intermediary that exposes administrative access to systems that should not be directly reachable. The architecture relies on network restriction, authentication, and session handling working together, because the bastion becomes the place where identity, transport, and logging converge. If the bastion is over-permissive, the control point becomes a multiplier rather than a gate. In identity terms, the bastion behaves like a high-value workload identity proxy for human operators, so its own permissions and auditability matter as much as the target host.

Practical implication: enforce least privilege on the bastion itself and log every forwarded hop separately.

SSH agent forwarding and credential exposure windows

SSH agent forwarding removes the need to copy a private key to a remote server, but it also creates an active credential delegation window during the session. The remote host can ask the local agent to authenticate elsewhere while the connection remains open, which means the trust boundary is temporal as well as technical. That is why forwarding is safer than storing keys on the server, yet still risk-bearing if the bastion or guest is compromised. The real issue is not key location alone, but how long delegated access remains usable and by whom.

Practical implication: limit agent forwarding to specific administrative workflows and disable it where the session does not require chained access.

Breaches seen in the wild

• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SSH bastion workflows expose a classic access-governance tension: convenience is often purchased by stretching trust across the session path. The tutorial shows a cleaner way to reach internal systems, but the security model still depends on a forwarded credential being accepted by an intermediary host. That makes the bastion a privileged identity relay, not just a network hop. Practitioners should treat chained SSH access as governance infrastructure, not only as an admin convenience.

Key forwarding reduces key sprawl, but it does not eliminate standing trust in the operator session. The private key stays on the endpoint, yet the session can still authenticate downstream systems through the agent. That means the security outcome depends on how tightly the bastion is scoped, monitored, and revoked when the access path changes. In NHI terms, the control problem is delegated access without full lifecycle visibility.

Delegated SSH trust window: the access model assumes the forwarded credential is used only within a tightly bounded administrative session. That assumption holds when the bastion is well controlled, but it fails if the session is reused, intercepted, or over-broadened across internal hosts. The implication is that access governance must account for ephemeral delegation paths, not just credential storage location.

Bastion design becomes an audit and revocation problem as much as an authentication problem. If the intermediary cannot prove who used which hop, when, and for what target, the access path is already too loose for mature governance. This is where SSH administration overlaps with NHI lifecycle thinking: who can initiate the session, what it can reach, and how quickly it can be withdrawn all matter. Practitioners should map bastion policy to explicit accountability boundaries.

Human administrative SSH patterns foreshadow the same governance failures seen in NHI and workload access. A privileged session that can pivot across systems behaves like a non-human access chain once the operator no longer controls each step manually. That is why bastion governance belongs in the same conversation as secrets handling, session logging, and privilege minimisation. The programme takeaway is to manage the access path as an identity object.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• Another 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• For the broader control model, see 52 NHI Breaches Analysis for the failure patterns that emerge when delegated access is left under-governed.

What this signals

Delegated SSH access should now be read as an identity governance pattern, not a niche admin technique. The same control gap appears whenever access is forwarded, proxied, or chained through an intermediary that is trusted to act on behalf of the operator. As environments add more machine-mediated hops, the programme question becomes whether the access path remains visible enough to audit and revoke.

With 5.7% of organisations having full visibility into their service accounts, per Ultimate Guide to NHIs, the gap is not just in credentials but in control paths. Bastions, forwarding agents, and other delegated session relays need the same scrutiny as NHI infrastructure because they carry privilege across trust boundaries. Teams that can see the relay but not the full chain will miss the failure mode until an incident forces reconstruction.

For practitioners

• Inventory every bastion as a privileged identity relay Document which internal hosts each bastion can reach, which users can initiate forwarding, and which sessions are logged end to end. Treat the bastion as a controlled access object, not just a jump box.
• Disable forwarding where chained access is unnecessary Turn off ssh-agent forwarding by default and permit it only for workflows that genuinely require a second hop. Reduce the number of environments where a forwarded agent can be invoked from a remote host.
• Bind session logs to target host and operator identity Record the initial login, the downstream internal host reached through the bastion, and the operator who initiated the chain. Without that linkage, revocation and forensics become guesswork after the session ends.
• Apply lifecycle rules to bastion access approvals Review who can use forwarding, who can approve access to the bastion, and how quickly those rights are removed when role changes occur. Include the bastion in access recertification and offboarding checks.

Key takeaways

• SSH bastion forwarding reduces key copying, but it does not remove the governance burden of delegated access.
• The scale of NHI visibility gaps shows why identity teams should treat bastion sessions as auditable control paths, not informal admin shortcuts.
• Teams that cannot log, bound, and revoke the full SSH chain will struggle to prove least privilege when access is used through an intermediary.

Key terms

• SSH Agent Forwarding: SSH agent forwarding lets a remote host ask the user’s local SSH agent to perform authentication without copying the private key onto that host. In governance terms, it is delegated access, so the security question is not only where the key lives but which systems are allowed to use the delegated session path.
• Bastion Host: A bastion host is a hardened intermediary system that mediates administrative access to internal assets not meant to be directly exposed. It concentrates control, logging, and trust into one place, which makes its own identity and access policy as important as the systems it reaches.
• Delegated Access Path: A delegated access path is a chain in which one identity or session is allowed to act through another system on the way to a target asset. It is common in SSH, service-to-service, and workload workflows, and it creates audit and revocation challenges when the chain is not fully visible.

Deepen your knowledge

SSH bastion access and delegated session governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are managing privileged access through jump hosts or forwarding agents, it is worth exploring.

This post draws on content published by StrongDM: How to SSH Through Bastion With Key, Part 2: Managing SSH keys. Read the original.