System and boundaries
SSH has transport, user authentication, and connection protocols. The client authenticates the server host, the server authenticates the user or client, and one encrypted connection can carry shell, command, subsystem, and forwarding channels.
Identity and channel flow
The client validates the server host key. The transport negotiates algorithms and keys. User authentication proves an allowed identity. The client then requests channels. The server applies operating-system and SSH policy to each session, command, subsystem, or forward.
Authority and evidence
Separate host identity, gateway identity, SSH user, operating-system account, original human or workload actor, certificate principals, command, and target. Record connection and channel evidence. A valid SSH login does not authorize every command or forwarded destination.
Failure and residual risk
Ignoring host-key changes enables interception. Shared keys erase accountability. Agent forwarding exposes delegated signing authority. Port forwarding can bypass network controls. Long-lived sessions can survive policy change. Terminal recording can miss side effects outside the session.
Pomerium boundary
Pomerium supports documented native SSH and tunneled access patterns. Operators own server host identity, operating-system accounts, command policy, forwarding rules, target isolation, session lifetime, and final system evidence.
Evaluation checklist
- How does the client authenticate the server host?
- Which human or workload identity maps to which SSH and operating-system principal?
- Which shell, command, subsystem, and forwarding channels are allowed?
- Can policy change or revocation terminate or bound existing sessions?
- Which target actions require evidence beyond the SSH connection?
