Moving Beyond Static SSH Keys with Teleport RBAC

The Risk of the Permanent SSH Key

Managing infrastructure access often starts with a simple ssh-keygen and a manual copy of a public key to authorized_keys. While this works for a handful of servers, it creates a scaling nightmare: keys are rarely rotated, offboarding employees requires scrubbing every single server, and there is no central record of who accessed what and why.

The core problem is that static keys are long-lived credentials. If a private key is leaked, the attacker has persistent access until the key is manually revoked. Teleport solves this by replacing static keys with short-lived certificates tied to a central identity provider (IdP).

Identity-Driven Access Control

Instead of managing a list of keys on every server, Teleport uses a unified Role-Based Access Control (RBAC) model. When a user logs in via an SSO provider (like Okta, GitHub, or Google), the Teleport Auth Service issues a short-lived X.509 or SSH certificate. This certificate is only valid for a few hours, meaning there is nothing to revoke manually when a user leaves the company—the certificate simply expires.

Access is governed by Roles. A role maps the user's identity traits (such as their SSO group) to specific permissions. These permissions include which OS users they can log in as and which nodes they can access based on node labels. This shifts the security model from "who has the key" to "who is the user and what is their current role."

Worked Example: Restricting Dev Access

Consider a scenario where you want developers to access only the development environment, and only for a limited window of time. You can achieve this by labeling your nodes and defining a specific role.

1. Label the Nodes

Ensure your development servers are labeled. This is typically done in the teleport.yaml configuration on the node or via the API:

# Example label on a dev server
teleport node label add env=dev

2. Define the Role

Create a role (e.g., dev-access) that restricts logins to nodes with the env=dev label. In the Teleport UI or via tctl, the role configuration would look like this:

# Conceptual RBAC configuration
roles:
  dev-access:
    allow:
      logins: ["ubuntu", "devuser"]
      node_labels:
        "env": "dev"
    options:
      max_session_ttl: 8h

3. The User Workflow

The developer then authenticates using the Teleport client (tsh) from their local terminal:

# Run on local machine
tsh login --proxy=teleport.example.com

After completing the SSO flow in the browser, the user can list available nodes and connect:

# List nodes matching the role
tsh ls

# Connect to a dev node
tsh ssh ubuntu@dev-server-01

If the user attempts to SSH into a production server (labeled env=prod), Teleport will deny the connection because the certificate issued to them does not contain the required label permissions.

Auditability via Session Recording

One of the most practical engineering benefits of this architecture is the integrated session recording. Because all traffic flows through the Teleport Proxy, every SSH session and Kubernetes exec is captured as a structured event stream.

Unlike a video recording, these are stored as text-based logs of the terminal output. This allows security teams to search for specific commands across all active sessions. These recordings are stored on the Auth Service or exported to external blob storage (like S3), ensuring that the audit trail remains intact even if the target server is destroyed.

The Control Plane Trade-off

Moving to a centralized access proxy introduces a critical dependency: the Teleport Auth Service. If the Auth Service goes offline, users cannot perform a tsh login to get new certificates. While existing sessions may continue to function for the duration of their TTL, new access is blocked.

To mitigate this, production environments should implement a High Availability (HA) deployment of the Auth and Proxy services. Additionally, it is essential to maintain a "break-glass" procedure—such as a highly secured, offline static key on a few critical nodes—to regain access if the entire Teleport cluster becomes unreachable.

Verifying Your Configuration

To verify that your RBAC and certificates are working as intended, run the following checks on your local machine after logging in:

• Check Certificate Validity: Run tsh status. Verify that the "Expires At" timestamp matches the TTL defined in your role.
• Test Boundary Access: Attempt to SSH into a node that does not match your role's labels. You should receive a permission denied error.
• Confirm Audit Trail: Perform a few commands in a session, disconnect, and then use the Teleport Web UI to replay the session and ensure the output matches your actions.