Bastions, forwarding, and port exposure | SSH: secure access and production diagnosis

Concept and mechanism

A bastion allows a target to be reached through an authorized intermediate point. ProxyJump organizes that path without requiring the private key to be copied to the bastion. Agent forwarding is different: it makes a connection to the local authentication agent available on the remote host. Even without obtaining private material, someone with sufficient access on that host may use the forwarded agent for authentication operations. Forwarding the agent therefore needs a concrete justification. A network hop does not automatically grant authorization at the final target.

Guided application

With local forwarding, a client-side port receives connections forwarded over SSH to a service reached from the remote side. In the authorized example ssh -N -L 127.0.0.1:15432:db.internal:5432 ops@bastion.example.test, the client listens only on loopback and db.internal is reached from the bastion. This removes neither database authentication nor network or forwarding policy. An active SSH session does not prove that the final service responds. If the listener already exists or the server rejects forwarding, investigate that condition before changing application credentials.

IN PRACTICE

A tunnel establishes its session, but the bastion cannot resolve db.internal. Diagnosis must observe resolution on the side opening the final connection.

Common pitfalls

Copying private keys to intermediate hosts; confusing active tunnels with healthy target services; unnecessarily exposing listeners.

Related topics: Automation and changes without losing access · SSH connection and server identity

Take this idea with you

Identify who listens, who resolves the final name, and who applies each authorization.

Create account

Reference: ssh(1): OpenSSH client · OpenSSH concepts and OpenBSD-current manuals consulted 2026-09-29; distribution defaults vary