SSH broker overview

VaultTerm doesn’t hand you a key and wish you luck. It is an audited access broker: when you open a session to a host, the server uses a vault credential to authenticate you, then tears everything down afterward. The connecting device never holds a standing key, and the whole session is on the record.

How a brokered session works

1. You request a host. You pick a connection profile (host, port, login user, auth method) — see Connecting to hosts. You never paste a key into a terminal.
2. The broker injects the credential just-in-time. The server reads the referenced credential from the vault, decrypts it in memory for that one authorized action, and uses it to authenticate to the target. With envelope encryption there is no plaintext at rest; the decrypted secret lives only for the life of the session.
3. The session runs. Interactive shells, single commands, port forwards, and file transfers all run over the same brokered SSH path. The connecting device exchanges terminal bytes with the broker, not the host’s private key.
4. It tears down. When the session ends, the in-memory secret is discarded. Nothing is left behind on the laptop, browser, or CLI to rotate later.

A credential can be flagged inject-only: the broker will still decrypt it in memory to authenticate a session, but no read, reveal, or export path ever returns its plaintext. A teammate can connect with a server or database secret they are never allowed to see, and the audit trail records that injection happened.

Everything is attributable

Every brokered action lands in the tamper-evident audit trail, tied to a specific user:

• Connecting, running a command, and opening an interactive shell are each recorded.
• SFTP operations — list, download, upload, mkdir, rename, delete — are recorded with the path and size.
• High-risk commands are intercepted before they run and require a fresh WebAuthn step-up; the block is itself audited (proven presence, not a self-declared flag).
• When session recording is enabled, the full terminal I/O is captured for review — see Session recording.

This is the difference between “someone on the team has access” and “this person ran this command on this host at this time.” VaultTerm gives you the second.

SFTP runs through the same path

File transfer isn’t a side door. SFTP uses the same brokered connection, the same vault credential, the same RBAC check on that credential’s vault, and the same audit trail as an interactive shell. There is no separate set of keys to manage for file movement.

Contrast: scattered private keys

The traditional alternative is a private key on every laptop and an authorized_keys file on every host. That model fails exactly where it matters:

Concern	Scattered private keys	VaultTerm broker
Where the key lives	On each device	In the vault, under envelope encryption
Rotation	Touch every host and device	Rotate centrally; nothing on devices to chase
Attribution	A shared key says nothing about who	Every session is tied to a user in the audit trail
Revocation	Hunt down copies and edit authorized_keys	Remove access centrally; no standing key to revoke
Secret exposure	The user holds the plaintext key	Inject-only secrets are never shown

For a fully keyless model on the host side, pair the broker with the SSH certificate authority, which mints short-lived certificates instead of distributing static keys.

Where to go next

• Connecting to hosts — create a connection profile and open a session.
• Session recording — capture and replay terminal and SFTP activity.
• SSH certificate authority — short-lived certs, no static keys on hosts.