Notifications
Clear all
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.
NHIMG editorial — based on content published by StrongDM: How to SSH Through Bastion With Key, Part 2: Managing SSH keys
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.
Questions worth separating out
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.
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.
Q: What breaks when bastion access is not logged end to end?
A: Revocation and forensics both fail.
Practitioner guidance
- 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.
- 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.
- 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.
What's in the full article
StrongDM's full tutorial covers the operational detail this post intentionally leaves for the source:
- Exact SSH commands for creating and loading a key on macOS and verifying the agent state.
- Step-by-step forwarding workflow for connecting from the bastion host to an internal guest system.
- The third-part logging setup that sends verbose session data off site for auditing.
- Environment-specific instructions that show how the bastion and guest hosts are configured in practice.
👉 Read StrongDM's tutorial on SSH bastion key forwarding →
SSH bastion key forwarding: what it means for access governance?
Explore further
08/06/2026 7:02 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: SSH bastion key forwarding shows where access control still breaks
