Auditing Ssh Trust And Agent Forwarding

Auditing SSH trust and agent forwarding: what a connected host can turn into your identity

Secure-shell security is usually discussed as ciphers and key lengths, which are largely solved. The unsolved part is trust: who can use your authentication, whose host key you accept without checking, and whose data shapes your client's behavior. A forwarded agent lets whatever host you land on authenticate as you to everything your key opens; a proxy-command or config entry pulled from an untrusted place runs on your machine or redirects your session; a disabled host-key check turns any network position into a man in the middle; a loose authorized-key entry hands more than intended. You find these by tracing where authentication and configuration flow and asking what a compromised or untrusted endpoint can do with them.

When to use

• You are auditing how users or automation establish secure-shell trust and what it reaches.
• Agents are forwarded, host keys are accepted, or client configuration comes from shared sources.
• A compromised or multi-tenant endpoint could abuse forwarded authentication or injected config.

Scope check

Audit secure-shell trust only for hosts, accounts, and automation you own or are authorized to assess. Using a forwarded agent or a key to reach systems outside scope is not part of the audit. If you can't name the authorization, stop.

The loop

1. Map where authentication is forwarded and to which hosts. Inventory the connections and automation that forward the authentication agent, and to what hosts the socket is exposed. A forwarded agent on a single-user, trusted bastion is contained; one exposed on a multi-user, internet-facing, or lower-trust host means anyone who can reach that socket authenticates as you to everything your key opens. Determine the trust of every host the agent reaches.

2. Check who can use an exposed agent socket. Where the agent is forwarded, check the socket's permissions and the host's other users and processes. A root or co-tenant on the far host can use the socket to sign challenges as you for the duration of the session, with no access to your key itself. An agent reachable by anyone but you on an untrusted host is the finding.

3. Trace client configuration and proxy directives to their source. Determine where the client's configuration, host aliases, and proxy-command directives come from, and whether any is influenced by an untrusted source: a configuration file checked into a shared repository, read from a world-writable path, or a host or option value built from attacker-controlled input. A proxy-command runs a local command when connecting; if its content or selection is attacker-influenced, connecting runs their command on your machine.

4. Check host-key verification. Determine how host keys are verified: strict checking against a trusted store, blind trust-on-first-use, or verification disabled entirely. Automation that disables checking or auto-accepts unknown keys accepts any machine in the middle; the first connection to a never-seen host over a hostile path is trusted forever. A disabled or blindly-accepting check is a standing interception exposure.

5. Audit authorized-key options. For keys that grant access, read the restrictions on each entry: a forced command that can be escaped through its arguments or an interactive option, a missing source restriction so the key works from anywhere, and agent, port, or session forwarding left enabled where it is not needed. A key meant for one narrow task that permits a shell, arbitrary forwarding, or use from any source grants far more than intended.

6. Confirm and record. Confirm by exercising the gap in scope: use an exposed agent socket to reach a host you should not, trigger an injected proxy-command, accept a substituted host key that a strict check would refuse, or escape a forced command. Kill the lead if agents are forwarded only to trusted, single-user hosts with a protected socket, configuration and proxy directives come only from trusted sources, host keys are strictly verified, and keys carry tight command, source, and forwarding restrictions. Record with the trust source and what it reached.

Where secure-shell trust leaks

• A forwarded agent is your identity on the far host. Whoever can reach the socket authenticates as you everywhere your key works, without ever holding the key. Forward it only to hosts you fully trust.
• A proxy-command is local execution. Configuration or a directive from an untrusted source runs their command on your machine, or silently reroutes your session, the moment you connect.
• Trust-on-first-use trusts the attacker if they are first. A disabled or blindly-accepting host-key check makes any network position a viable man in the middle.
• A forced command is only as strong as its escapes. Argument injection, an interactive option, or permitted forwarding turns a restricted key back into a general one.
• A key without a source restriction works from anywhere it leaks to. Restrict where a key may be used, not only what it may do.

Worked example (a confirm and a kill)

Confirm. A deployment pipeline forwards its authentication agent to every host it touches, including a shared build host where other tenants have a shell. A co-tenant on that host uses the exposed agent socket to authenticate as the pipeline identity to a production host the pipeline's key also opens. Confirmed agent-forwarding abuse to lateral movement, high, remediation = stop forwarding the agent to shared hosts, use per-host constrained keys or a short-lived certificate, and confine any needed forwarding to a single-tenant jump host.

Kill. The agent is forwarded only to a single-tenant, strictly-controlled jump host with a user-only socket; client configuration and proxy directives come only from root-owned, non-writable paths with no attacker-influenced values; host keys are verified strictly against a managed store with no auto-accept; and every authorized key carries a non-escapable forced command, a source restriction, and forwarding disabled. Every abuse attempt fails. Killed, kill_reason = "agent confined to a trusted single-tenant host, config and proxy from trusted sources only, strict host-key verification, keys restricted by command, source, and forwarding."

Rationalizations to reject

• "Forwarding the agent is convenient." → It is your identity on every host you land on. Convenient and, on any shared or lower-trust host, a full lateral-movement primitive.
• "They would need my private key." → No. A forwarded agent signs challenges as you without the key ever leaving your machine; reaching the socket is enough.
• "We disable host-key checking so automation does not hang." → Then automation trusts any machine in the middle. Pin the keys and manage the store instead.
• "The key is locked to a forced command." → Can the command be escaped through its arguments or an interactive option, and is forwarding still allowed? A forced command with an escape is not a restriction.
• "The config is just our standard file." → From where - a shared repository, a writable path? A proxy-command from an untrusted source runs on your machine when you connect.

Executing this in practice

You need the map of where agents are forwarded and to which hosts, the trust and multi-tenancy of those hosts and the permissions on any forwarded socket, the sources of client configuration and proxy directives, the host-key verification posture, and the option set on every authorized key. The audit is tracing trust: for each, ask what an untrusted or compromised endpoint on the far side can do with it. Reading the intended setup tells you the design; following the trust tells you the exposure.

Related

• hunting-non-human-identity-and-secret-reachability - the keys and forwarded identities here are machine credentials; trace how far each actually reaches.
• auditing-declared-vs-used-permissions - a key or forwarded agent that grants more than its task needs is an over-grant in this form.
• hunting-iam-privilege-escalation-paths - agent-forwarding lateral movement is the on-host analog of chained identity assumption in the cloud.
• enumerating-snmp-exposure - a sibling network-service trust audit in the same lane.
• FINDING-SCHEMA.md - source = the forwarded socket, injected directive, or unverified key, sink = authentication or command execution as an unintended identity, evidence = what it reached.