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 still decrypts it in memory to authenticate a session, but the reveal, copy, share, borrow and export paths all refuse it: it does not appear in the interface, in a share link, in a vault export, or in a client’s offline copy. Every injection is recorded in the audit trail.

What inject-only is not. It is not a barrier against the people who are allowed to use the credential. Anyone who can read the credential’s vault can create a connection profile that uses it and choose the host that profile points at — including a host they control, which receives the secret in the clear when the broker authenticates to it. Inject-only keeps a secret off the screen and out of copies and exports; it does not make a credential safe to hand to someone you would not trust with its plaintext. Treat it as a way to keep working secrets out of sight, not as a containment boundary, and scope vault membership accordingly.

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	The secret stays in the vault; inject-only also keeps it out of the interface and exports

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.