How to Set Up Teleport SSH Access on Linux with Short-Lived Certificates 2025

Why Replace SSH Keys with Teleport?

Traditional SSH key management creates significant security risks. Static SSH keys are long-lived, difficult to rotate, and represent a massive attack surface if compromised. When a developer leaves your team or changes roles, revoking their access requires manual key rotation across multiple servers. Teleport solves this by replacing long-lived SSH keys with automatically-expiring certificates issued by a central certificate authority.

If you're managing more than a handful of servers, or you need to enforce audit trails for compliance, migrating to Teleport's certificate-based authentication is a practical improvement over traditional SSH key management.

Understanding Teleport's Architecture for SSH

Teleport operates as a single Go binary that sits between your users and your infrastructure. Instead of connecting directly to servers via SSH, users authenticate to a Teleport proxy, which then issues short-lived certificates (typically valid for 12 hours by default, configurable down to 1 minute). These certificates are cryptographically signed and can only be used during their validity window.

The key components are:

• Teleport Auth Server: Issues certificates and enforces access policies
• Teleport Proxy: Entry point for user connections and session recording
• Teleport Node Agent: Runs on each Linux server you want to protect
• Certificate Authority (CA): Signs all certificates with automatic expiration

Installing Teleport on Your Linux Infrastructure

Start by downloading the latest Teleport binary for your Linux distribution. Teleport provides pre-built binaries for amd64 and ARM64 architectures.

# Download Teleport (replace VERSION with current release)
VERSION=15.3.0
wget https://cdn.teleport.dev/teleport-v${VERSION}-linux-x86_64-bin.tar.gz

# Extract and install
tar -xzf teleport-v${VERSION}-linux-x86_64-bin.tar.gz
sudo mv teleport/tctl teleport/teleport /usr/local/bin/
sudo chmod +x /usr/local/bin/tctl /usr/local/bin/teleport

# Verify installation
teleport version

For production deployments, use your system's package manager:

# Ubuntu/Debian
sudo apt-get install teleport

# RHEL/CentOS
sudo yum install teleport

Configuring Your First Teleport Cluster

Create a minimal configuration file at /etc/teleport.yaml:

# /etc/teleport.yaml
version: v3
telemetry:
  enabled: false

global:
  data_dir: /var/lib/teleport

auth_service:
  enabled: true
  listen_addr: 0.0.0.0:3025
  public_addr: teleport.example.com:3025
  
proxy_service:
  enabled: true
  listen_addr: 0.0.0.0:3023
  public_addr: teleport.example.com:443
  web_listen_addr: 0.0.0.0:3080
  
ssh_service:
  enabled: true
  listen_addr: 0.0.0.0:3022

Replace teleport.example.com with your actual domain or IP address. This configuration enables all three core services: authentication, proxy, and SSH node access on a single machine (suitable for testing; production deployments separate these).

Launching Teleport and Creating Your First User

Start the Teleport daemon:

sudo systemctl start teleport
sudo systemctl enable teleport

Once running, use tctl to create your first user with certificate-based authentication:

# Log in to the auth server (locally, if on same machine)
sudo tctl status

# Create a user 'admin' with built-in roles
sudo tctl users add admin --roles=admin

# The command outputs a signup link
# Copy and open it to set your password and configure MFA

Enrolling Linux Nodes into Teleport

On each Linux server you want to manage through Teleport, install the Teleport node agent:

# On the target Linux server
sudo teleport start --roles=node \
  --auth-server=teleport.example.com:3025 \
  --token=<generated-join-token>

Generate a join token from your auth server:

# On the auth server machine
sudo tctl tokens add --type=node --ttl=1h

This outputs a token (valid for 1 hour) that the node uses to authenticate and join the cluster. Once joined, the node receives its own certificate and starts accepting SSH connections through the proxy.

Obtaining Short-Lived SSH Certificates

As a user, after logging into Teleport, request an SSH certificate:

# Install tsh (Teleport client)
tsh login --proxy=teleport.example.com:443 --user=admin

# After authentication, your certificate is stored in ~/.tsh/keys/
# By default, it expires in 12 hours

# Connect to a node using the certificate
tsh ssh admin@node-hostname

The tsh client automatically manages your certificate lifecycle. When your certificate expires, tsh ssh prompts you to re-authenticate before connecting.

Configuring Certificate Validity Duration

Adjust how long certificates remain valid by editing the auth service configuration:

auth_service:
  enabled: true
  
  # Maximum certificate TTL across all roles
  max_session_ttl: 12h
  
  # User-requested certificate duration (must be <= max_session_ttl)
  token_lifetime: 1h

For sensitive systems, reduce this to 1 hour or 30 minutes. For development environments, 12-24 hours is reasonable.

Enforcing Just-In-Time (JIT) Access Requests

Teleport enables elevated access only when explicitly requested. Define a role that requires approval:

kind: role
metadata:
  name: restricted-admin
spec:
  allow:
    node_labels:
      environment: production
    request:
      roles:
        - admin
  deny:
    node_labels:
      environment: test

When a user with the restricted-admin role attempts to access production servers, they must submit an access request. An admin reviews and approves it before the user's certificate is issued.

Auditing SSH Sessions

Teleport records all SSH connections. Access the audit log:

# View recent events
sudo tctl get events --limit=50

# Download session recording
sudo tctl get session_recording --id=<session-id>

Every keystroke and command output is captured and timestamped, providing compliance audit trails without requiring additional logging infrastructure.

Common Pitfalls and Solutions

Token Expiration: Join tokens expire (default 30 minutes). Regenerate if nodes fail to connect during initial setup.

Certificate Already Exists: If reusing a hostname, clear old certificates: sudo rm -rf /var/lib/teleport/*.

Firewall Rules: Ensure port 3025 (auth), 3023 (proxy), and 3022 (SSH) are accessible between clients, proxy, and nodes.

Hostname Resolution: Teleport uses hostname-based routing. All clients must resolve teleport.example.com to your proxy's IP.

Migrating from Traditional SSH Keys

This transition doesn't require immediate wholesale replacement. Run Teleport alongside traditional SSH during a transition period. Remove password authentication and require key-based auth while Teleport stabilizes. Once users consistently use tsh, disable direct SSH key access on servers.

Next Steps

For production deployments, explore Teleport's cloud-hosted option or implement high-availability auth/proxy clusters. Integrate with OIDC providers for SSO, enforce multi-factor authentication, and implement attribute-based access control (ABAC) based on user properties like team or access level.