Tutorials

Broker Your First SSH Session with Recording and Policy

Time: 15 minutes Difficulty: Intermediate Tools: Web UI, SSH client
Outcome. You'll SSH into a target server through CoreLink — authenticated with an ephemeral certificate, policy-gated at the command level, and fully recorded (TTY in, TTY out, gzip-compressed) for audit replay. At no point do you handle a long-lived SSH key.

Prerequisites

Step 1 — Enable CA-signed SSH on the target

CoreLink issues ephemeral SSH certificates signed by a per-tenant CA. The target needs to trust that CA. From the CoreLink UI: PKI → SSH CAs → your tenant's SSH CA. Copy the public key (the full ssh-ed25519 AAAA... line).

On the target server:

echo "ssh-ed25519 AAAA... corelink-tenant-ca" | sudo tee /etc/ssh/trusted-corelink-ca.pub

sudo tee -a /etc/ssh/sshd_config <<'EOF'
TrustedUserCAKeys /etc/ssh/trusted-corelink-ca.pub
EOF

sudo systemctl reload sshd

Any SSH client presenting a certificate signed by this CA will authenticate automatically. Revoking CoreLink's certificate issuance immediately revokes all access — no CA-level key distribution to individual hosts.

Step 2 — Register the SSH target in CoreLink

UI: Sessions → Targets → New SSH Target. Fill in:

Save. The target appears in the list with status "Unverified".

Step 3 — Pin the target's host key

Host-key pinning prevents MITM on the CoreLink → target leg. On the target:

sudo cat /etc/ssh/ssh_host_ed25519_key.pub
# ssh-ed25519 AAAAC3Nza... root@demo-web-1

Copy that line. In CoreLink, open the target's detail page and paste it into Host Key Fingerprint. Save. Status flips to "Verified". CoreLink will now refuse to connect if the host key ever changes — the outbound leg is MITM-proof.

Step 4 — Attach a command policy

Policies control both cert capabilities (port forwarding, agent forwarding) and command blocking. On the target's detail page, click Policy and configure:

Save. CoreLink's command interceptor buffers keystrokes, checks the first token against these rules before forwarding Enter, and rejects denied commands with a visible notice in the session.

Scope note: the interceptor checks the typed command; it doesn't sandbox shell expansion (subshells, variable expansion, heredocs can bypass if the rule is written naively). Layer it with sudo-less design and ForceCommand where possible. Covered in the session brokering use case.

Step 5 — Grant yourself access

On the target's detail page, click Access → Grant Access. Give yourself:

Save. For JIT workflows, replace direct grants with approval-gated access requests — see Approvals.

Step 6 — Broker and record a session

Back on the target detail page, click Connect. CoreLink opens a WebSocket-backed terminal in the browser. The session:

Try the policy:

ubuntu@demo-web-1:~$ ls
# file1.txt  logs/  README.md

ubuntu@demo-web-1:~$ sudo apt update
# Blocked by policy: 'sudo' is not permitted on this target.

ubuntu@demo-web-1:~$ rm -rf /
# Blocked by policy: destructive command 'rm -rf' matched preset rule.

Both blocked commands are visible to you in the terminal and recorded in the audit event stream with status=denied.

Step 7 — Replay the recording

Close the session. In the UI: Sessions → Records. Your session appears with duration, actor, target, and a replay button. Click it — TTYRec replays with scrubbing controls, so you can fast-forward, pause, and jump to specific timestamps. This is the artifact that goes into compliance evidence packages.

Verify

Three things you should confirm worked:

  1. Cert-only auth. Check ~/.ssh/authorized_keys on the target — there's no CoreLink-specific entry because the cert is signed by the trusted CA.
  2. Policy enforcement. The two blocked commands above showed the policy rejection in real-time.
  3. Recording. The session record exists and replays cleanly.

Next steps