SSH Access

Overview

This guide covers JIT SSH key access to Linux servers using the Britive Access Broker. At checkout, the broker generates an RSA key pair and adds the public key to the user’s ~/.ssh/authorized_keys on the target host. At checkin, the key is removed.

Two patterns are available:

Standard — one key per user per host. Suitable for single-session workflows.
TRX-tagged — keys are tagged with a transaction ID, enabling multiple concurrent sessions for the same user without checkin collisions.

Before You Begin

The broker is running and connected (see Getting Started)
The broker host has ssh-keygen available
The target Linux host is reachable from the broker (port 22)
The broker service account can write to the target user’s home directory — or the broker runs scripts directly on the target host

Pattern 1 — Standard SSH Key

Full scripts: Linux/permissions/temp-ssh-key/

At checkout, a new RSA key pair is generated, the public key is appended to authorized_keys, and the private key is returned to the user. At checkin, any key matching the user’s email is removed.

Environment variables:

Variable	Default	Notes
`BRITIVE_USER_EMAIL`	—	Injected by Britive — user’s email, used to derive the Linux username
`BRITIVE_SUDO`	`0`	Set to `1` to grant passwordless sudo
`BRITIVE_HOME_ROOT`	`home`	Base directory for user home paths (e.g. `home` → `/home/<user>`)
`KILL_SESSION`	`0`	Set to `1` to kill active SSH sessions at checkin

Checkout — generate key and add to authorized_keys:

Linux/permissions/temp-ssh-key/checkout.sh

USERNAME="${BRITIVE_USER_EMAIL%%@*}"
USERNAME="${USERNAME//[^a-zA-Z0-9]/}"

useradd -m ${USERNAME} 2>/dev/null

SSH_PATH=/${BRITIVE_HOME_ROOT:-"home"}/${USERNAME}/.ssh
ssh-keygen -q -N '' -t rsa -C $BRITIVE_USER_EMAIL -f $SSH_PATH/britive-id_rsa

# Append the new public key to authorized_keys
cat $SSH_PATH/britive-id_rsa.pub >> $SSH_PATH/authorized_keys
chmod 600 $SSH_PATH/authorized_keys

# Optionally grant sudo
[ "$BRITIVE_SUDO" != "0" ] && echo "$USERNAME ALL=(ALL) NOPASSWD:ALL" > /etc/sudoers.d/$USERNAME

cat $SSH_PATH/britive-id_rsa   # private key returned to user

Checkin — remove the key and clean up:

Linux/permissions/temp-ssh-key/checkin.sh

# Remove all lines containing the user's email from authorized_keys
grep -v "${BRITIVE_USER_EMAIL}" $SSH_PATH/authorized_keys > $SSH_PATH/authorized_keys.tmp
mv $SSH_PATH/authorized_keys.tmp $SSH_PATH/authorized_keys

# Remove sudo entry if it exists
rm -f /etc/sudoers.d/${USERNAME}

# Optionally kill active SSH sessions
[ "$KILL_SESSION" = "1" ] && pkill -u "${USERNAME}" sshd || true

Pattern 2 — TRX-Tagged Keys (Concurrent Sessions)

Full scripts: Linux/permissions/temp-ssh-key/ (checkout_with_trx_id.sh, checkin_with_trx_id.sh)

Each key is tagged with a transaction ID (trx-id=<TRX>). Checkin removes only the key for that transaction, leaving other active sessions unaffected. Use this pattern on shared servers where multiple users — or the same user — may have concurrent checkouts.

Additional variable:

Variable	Notes
`TRX`	Injected by Britive — unique transaction ID per checkout

Checkout — tag the public key with the TRX ID:

Linux/permissions/temp-ssh-key/checkout_with_trx_id.sh

TRX=${TRX:-"default-trx-id"}

ssh-keygen -q -N '' -t rsa -C $BRITIVE_USER_EMAIL -f $SSH_PATH/britive-id_rsa

# Append TRX marker to the public key comment
PUB_KEY_CONTENT="$(cat $SSH_PATH/britive-id_rsa.pub) trx-id=${TRX}"
echo "$PUB_KEY_CONTENT" >> $SSH_PATH/authorized_keys

Checkin — remove only the matching TRX key:

Linux/permissions/temp-ssh-key/checkin_with_trx_id.sh

# Remove only the line matching both user email and TRX ID
grep -v "${BRITIVE_USER_EMAIL}.*trx-id=${TRX}" $SSH_PATH/authorized_keys \
  > $SSH_PATH/authorized_keys.tmp
mv $SSH_PATH/authorized_keys.tmp $SSH_PATH/authorized_keys

Use TRX-tagged keys on any server where multiple sessions may be active simultaneously. Standard checkin removes all keys for the user — it will terminate other active sessions.

Configure in Britive

Create a response template

Go to Resource Manager → Response Templates → New Template. Add a field that surfaces the SSH private key returned by the checkout routine.

Create a permission

Go to Resource Manager → Resource Type Permissions → New Permission. Set Language to Shell.

Paste the checkout and checkin routines. For concurrent-session environments use the TRX-tagged variants.

Declare variables:

Variable	System defined	Notes
`BRITIVE_USER_EMAIL`	Yes	Injected automatically
`TRX`	Yes	Injected automatically (TRX-tagged variant only)
`BRITIVE_SUDO`	No	`0` or `1`
`BRITIVE_HOME_ROOT`	No	Home directory base on the target host
`KILL_SESSION`	No	`0` or `1`

Under Response Templates, attach the template you created.

Create a profile

Go to Resource Manager → Profiles → New Profile. Set an expiration (e.g. 1h). Under Associations, select the resource label(s) covering the target Linux servers. Under Permissions, add the permission above.

Add a policy

Under Policies, assign members (users or tags) and set any approval or time-of-access conditions.

linux-ssh.tf

# Resource type — defines the LinuxServer class
resource "britive_resource_manager_resource_type" "linux" {
  name        = "LinuxServer"
  description = "Linux SSH server"

  parameters {
    param_name   = "hostname"
    param_type   = "string"
    is_mandatory = true
  }
  parameters {
    param_name   = "port"
    param_type   = "string"
    is_mandatory = true
  }
}

# Permission — checkout/checkin routines
resource "britive_resource_manager_resource_type_permission" "ssh" {
  name             = "SSH-TempKey-Access"
  resource_type_id = britive_resource_manager_resource_type.linux.id
  description      = "JIT SSH access via temporary key"
  code_language    = "Shell"

  checkout_code_file = "${path.module}/scripts/checkout_with_trx_id.sh"
  checkin_code_file  = "${path.module}/scripts/checkin_with_trx_id.sh"

  variables        = ["BRITIVE_USER_EMAIL", "TRX", "BRITIVE_SUDO", "BRITIVE_HOME_ROOT", "KILL_SESSION"]

  # The checkout routine prints the raw private key on stdout —
  # show the script output directly instead of a response template
  show_orig_creds = true
}

# Resource label — categorize servers by environment
resource "britive_resource_manager_resource_label" "env" {
  name        = "environment"
  description = "Deployment environment"
  label_color = "#2563eb"

  values { name = "Production";  description = "Production servers" }
  values { name = "Staging";     description = "Staging servers" }
}

# Resource — a specific Linux server
resource "britive_resource_manager_resource" "web01" {
  name          = "prod-web-01"
  description   = "Production web server"
  resource_type = britive_resource_manager_resource_type.linux.name

  parameter_values = {
    hostname = "prod-web-01.internal"
    port     = "22"
  }

  resource_labels = {
    environment = "Production"
  }
}

# Profile — JIT SSH access profile
resource "britive_resource_manager_profile" "ssh" {
  name                = "Linux-SSH-Access"
  description         = "JIT SSH key access to Linux servers"
  expiration_duration = 3600000   # 1 hour in milliseconds

  associations {
    label_key = "environment"
    values    = ["Production"]
  }
}

# Profile permission — link profile to the SSH permission
resource "britive_resource_manager_profile_permission" "ssh" {
  profile_id = britive_resource_manager_profile.ssh.id
  name       = britive_resource_manager_resource_type_permission.ssh.name
  version    = "latest"

  variables {
    name              = "BRITIVE_SUDO"
    value             = "0"
    is_system_defined = false
  }
  variables {
    name              = "BRITIVE_HOME_ROOT"
    value             = "home"
    is_system_defined = false
  }
  variables {
    name              = "KILL_SESSION"
    value             = "0"
    is_system_defined = false
  }
}

# Profile policy — who can check out
resource "britive_resource_manager_profile_policy" "ssh" {
  profile_id  = britive_resource_manager_profile.ssh.id
  policy_name = "SSH-Access-Policy"

  members = jsonencode({
    tags             = [{ name = "linux-users" }]
    users            = []
    serviceIdentities = []
    aiIdentities     = []
  })

  condition   = jsonencode({ ipAddress = null, timeOfAccess = null })
  access_type = "Allow"
  consumer    = "resourceprofile"
  is_active   = true
  is_draft    = false
}

Verify

Check out the profile

In the Britive console, navigate to My Access → find the profile → Check Out. The SSH private key appears in the checkout response.

Save the key and connect

# Save the key from the checkout response
chmod 600 ~/britive-key.pem

# Connect — username is derived from your email (e.g. jdoe@example.com → jdoe)
ssh -i ~/britive-key.pem jdoe@<target-host>

Check in

Return to My Access → Check In.

Confirm access is revoked

ssh -i ~/britive-key.pem jdoe@<target-host>
# Expected: Permission denied (publickey)

Troubleshoot

Symptom	Cause	Fix
`Permission denied (publickey)` immediately after checkout	Key not added to `authorized_keys`	Check broker logs; verify `BRITIVE_HOME_ROOT` matches the actual home path
Checkin removes other users’ sessions	Using standard variant on a shared server	Switch to TRX-tagged scripts
`sudo: command not found` after checkout with `BRITIVE_SUDO=1`	sudoers entry not written	Confirm broker runs as root or has write access to `/etc/sudoers.d/`
Key remains after checkin	Checkin routine ran against wrong home path	Verify `BRITIVE_HOME_ROOT` is consistent between checkout and checkin routines

Last updated on July 8, 2026

Getting Started Remote SSH Access