Topic starter
08/06/2026 5:04 pm
TL;DR: SSH bastion workflows can simplify remote administration without storing private keys on servers, but they also preserve a trust model that depends on forwarding, agent handling, and tightly scoped host access, according to StrongDM’s tutorial. The practical lesson is that convenience does not remove identity risk when credentials still move through the session path.
Editorial analysis by NHI Mgmt Group, based on content published by StrongDM: “How to SSH Through Bastion With Key | Part 2 - Tutorial”.
Key questions
Q: What breaks when SSH agent forwarding is used without tight bastion scoping?
A: The control breaks when a forwarded session can reach more internal systems than the admin actually needs.
Q: Why does storing the private key only on the admin machine not eliminate SSH access risk?
A: Because the key location is only one part of the control model.
Q: Where do bastion host workflows most often fail in practice?
A: They fail when the bastion is treated as a convenience layer instead of a governed privilege boundary.
Practitioner guidance
- Tighten bastion destination scope Limit each bastion host to only the internal systems it actually needs to reach, and separate administrative paths by environment or function so the jump point cannot become a general-purpose relay.
- Treat forwarded sessions as privileged access Require the same review discipline for SSH forwarding paths that you apply to other privileged sessions, including destination limits, approval scope, and logging of the handoff into internal hosts.
- Separate key storage from session authority Keep private keys on the admin device, but do not assume that alone reduces risk.
Bottom line: SSH agent forwarding changes where the trust sits, but not whether the session remains privileged.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
08/06/2026 7:02 pm
SSH agent forwarding is an access-path control, not a secret-management cure. The private key may remain off the server, but the session still carries delegated trust from the admin machine to the bastion and then to the target host. That means the real control problem is who can inherit that trust and how far it can travel. Practitioners should treat forwarded SSH access as a privileged delegation chain, not a simple login convenience.
A question worth separating out:
Q: How should teams govern forwarded SSH access in a PAM programme?
A: Teams should govern forwarded SSH access as a session-level privileged path, not as a simple transport detail. That means defining who can use the forwarding flow, which hosts it can reach, and how much internal access the bastion may inherit before the session ends.
👉 Read our full editorial: SSH bastion key forwarding shows where access control still breaks
This post was modified 4 days ago by NHI Mgmt Group