Introduction

You manage a dozen or even dozens of VPS instances, each with its own SSH key. Then the problems start:

• An employee leaves, and you manually log into every server to remove their public key — you miss one and leave a backdoor;
• In an emergency, you need to give a colleague temporary access, so you send the private key via WeChat, where it lives on forever in chat history;
• A security audit reveals someone used the same key for both production databases and dev machines — permissions were completely mixed;
• When something goes wrong, there’s no record of who ran what command. SSH logs only show IP and timestamp, not command content.

The root cause of these pain points is this: SSH was designed for trusted network environments, not for zero-trust access control in modern cloud-native architectures.

Teleport is an open-source access platform that replaces SSH keys with short-lived, certificate-based authentication. It provides RBAC (Role-Based Access Control), session recording and audit, and dynamic infrastructure discovery. Most importantly, it can completely replace SSH as the access entry point for your VPS without modifying existing server configurations.

This article will walk you through deploying Teleport from scratch, upgrading your VPS access security from “scattered key management” to “zero-trust governance”.

Why SSH Key Management Is So Painful

Before understanding Teleport, let’s examine the deeper problems with traditional SSH access.

Problem 1: Key Lifecycle Is Impossible to Control

SSH keys are valid forever once generated — unless you manually rotate them. This means:

• A single key can be used indefinitely with no expiration mechanism;
• If a key is lost or leaked, you must find every server that uses it and remove it manually;
• When an employee leaves, you can’t possibly remember which servers they accessed.

Problem 2: Permission Granularity Is Too Coarse

SSH only provides a binary “can/cannot login” check. Once logged in — who you are, what commands you can run, what resources you can access — SSH doesn’t care at all.

You need additional tools (sudo, sudoers, pam) to restrict permissions, but these tools work independently, are complex to manage, and are error-prone.

Problem 3: Audit Capability Is Nearly Nonexistent

SSH logs only record: who, from which IP, at what time they logged in. They don’t record:

• What commands were executed after login;
• Which files were transferred;
• What operations were performed during the session.

When a security incident occurs, you have almost no way to trace it.

Problem 4: Key Distribution Is Insecure

Common practices for sharing private keys with colleagues include:

• Sending .pem files via email/chat;
• Having the other party add their key to the server’s authorized_keys;
• Writing keys directly in shared documents.

Whichever method you choose, private keys are exposed in plaintext during transit and storage.

Teleport’s Core Design Philosophy

Teleport’s design philosophy can be summed up in one sentence: replace long-lived keys with short-lived certificates, replace distributed configuration with centralized policy.

Certificate-Based Authentication

Teleport doesn’t rely on SSH key pairs. Instead, it issues short-lived, role-bound access certificates:

• Certificates have configurable validity periods (default 12 hours, max 10 days);
• Certificates are bound to user roles and attributes, automatically expiring;
• Users only hold their private key (cached locally), no need to manage server-side authorization lists.

Zero Trust Architecture

Teleport assumes the network is untrusted — all access requires authentication and authorization:

• Every connection verifies user identity and permissions;
• Supports MFA (TOTP, WebAuthn, SAML);
• Supports IP whitelisting and geolocation restrictions.

Centralized Policy Management

All access rules are defined in one place:

• RBAC: define who can access which resources and as what identity;
• Dynamic infrastructure discovery: new servers are automatically discovered and policy-applied when joining the cluster;
• Policy as code: configuration files can be version-controlled.

Complete Session Audit

Teleport records complete information for every session:

• Terminal session recordings (Terry Studio format);
• Command execution history;
• File transfer records;
• Playback and audit support.

Architecture Overview

Teleport uses a client-server architecture with these core components:

┌─────────────────────────────────────────────────────┐
│                  User Client                         │
│  tsh CLI / Web UI / kubectl / rdp / ssh             │
└──────────────────┬──────────────────────────────────┘
                   │ HTTPS + mTLS
┌──────────────────▼──────────────────────────────────┐
│              Teleport Auth Server                     │
│  · User authentication (MFA)                         │
│  · Certificate issuance                              │
│  · Session recording                                 │
│  · Policy storage                                    │
└──────────────────┬──────────────────────────────────┘
                   │
     ┌─────────────┼─────────────┐
     │             │             │
┌────▼────┐  ┌────▼────┐  ┌────▼────┐
│Proxy    │  │Proxy    │  │Proxy    │
│(SSH)    │  │(HTTPS)  │  │(K8s)    │
└────┬────┘  └────┬────┘  └────┬────┘
     │             │             │
     │    ┌────────┴────────┐   │
     │    │  Teleport Nodes  │   │
     │    │  (VPS 1, VPS 2..)│   │
     │    └─────────────────┘   │
     │                          │
     └─────── External Users ────┘

• Auth Server: Control plane — handles authentication, authorization, certificate issuance, and session recording;
• Proxy Server: Data plane — handles encrypted connection forwarding, exposes a unified access entry point;
• Node: Managed servers running the Teleport agent;
• tsh: User client, replacing the ssh command.

Deploying Teleport: Three Steps

Step 1: Deploy Auth + Proxy Server

We recommend deploying the Auth Server and Proxy Server on the same VPS (suitable for small teams).

# Download Teleport
curl -fsSL https://apt.releases.teleport.dev/gpg | sudo dd of=/usr/share/keyrings/teleport-archive-keyring.asc
echo "deb [signed-by=/usr/share/keyrings/teleport-archive-keyring.asc] https://apt.releases.teleport.dev/ubuntu jammy stable" | sudo tee /etc/apt/sources.list.d/teleport.list
sudo apt-get update && sudo apt-get install teleport-usm

# Generate self-signed certificates (use Let's Encrypt in production)
sudo teleport cert create --type=host --host=your-domain.com --out=file

# Create Teleport configuration
sudo tee /etc/teleport.yaml <<EOF
auth_service:
  enabled: "yes"
  listen_addr: 0.0.0.0:3025
  cluster_name: vps-access
  authentication:
    type: local
    second_factor: on
    webauthn:
      rp_id: your-domain.com
  tokens:
    - proxy,node:teleport-token-xxxx
    - proxy:teleport-proxy-token-xxxx

proxy_service:
  enabled: "yes"
  listen_addr: 0.0.0.0:443
  public_addr: your-domain.com
  acme:
    enabled: "yes"
    email: admin@your-domain.com

ssh_service:
  enabled: "yes"
  listen_addr: 0.0.0.0:3023

logging:
  output: /var/log/teleport.log
  error_output: /var/log/teleport-error.log
  audit_events:
    output: /var/log/teleport-auth.log
EOF

# Start the service
sudo systemctl enable teleport && sudo systemctl start teleport

# Create initial admin account
tctl auth sign --type=user --ttl=0 --credentials=file /tmp/user.crt /tmp/user.key
sudo teleport user add --roles=editor,access --logins=root,ubuntu $(whoami) --output=insecure

Step 2: Add VPS Nodes to the Teleport Cluster

Install the Teleport Node agent on every VPS you want to manage:

# Run on all target VPS instances
curl -fsSL https://apt.releases.teleport.dev/gpg | sudo dd of=/usr/share/keyrings/teleport-archive-keyring.asc
echo "deb [signed-by=/usr/share/keyrings/teleport-archive-keyring.asc] https://apt.releases.teleport.dev/ubuntu jammy stable" | sudo tee /etc/apt/sources.list.d/teleport.list
sudo apt-get update && sudo apt-get install teleport-usm

# Generate node registration token
sudo teleport token add --type=host --ttl=24h node-token

# Configure the node
sudo tee /etc/teleport.yaml <<EOF
auth_token: node-token
auth_servers:
  - your-domain.com:443
ssh_service:
  enabled: "yes"
  commands:
    - name: hostname
      command: [hostname]
      format: text
  terminal_session_server_selection: proxy
logging:
  output: /var/log/teleport.log
  error_output: /var/log/teleport-error.log
EOF

# Enable and restart
sudo systemctl enable teleport && sudo systemctl restart teleport

Step 3: Configure RBAC Policies

Teleport has a built-in flexible RBAC system. You can define roles using tctl commands or YAML files:

# View built-in roles
tctl get roles

# Create a custom role: read-only auditor
cat > /tmp/read-only-auditor.yaml <<EOF
kind: role
version: v5
metadata:
  name: readonly-auditor
spec:
  allow:
    logins: ["root", "ubuntu"]
    nodes:
      - ".*"
    rules:
      - resources: ["audit_log"]
        verbs: ["list", "read"]
      - resources: ["session"]
        verbs: ["list", "read", "play"]
  deny:
    logins: []
    nodes: []
EOF

tctl create -f /tmp/read-only-auditor.yaml

# Assign role to user
tctl users roles add alice,readonly-auditor

Core role capabilities comparison:

Daily Usage: Using tsh Instead of ssh

After installing the client tool, you can use tsh to access all registered VPS instances:

# Login to Teleport cluster
tsh login --proxy=your-domain.com --user=alice

# List all available servers
tsh nodes

# Connect like ssh (but more powerful)
tsh ssh root@web-server-01

# View session history
tsh sessions

# Replay a session
tsh play <session-id>

# Export audit logs
tsh audit --from=2026-08-01 --to=2026-08-29 > audit-report.json

tsh vs ssh Comparison

Advanced: Integrating With Existing Toolchains

GitHub Actions Integration

# .github/workflows/deploy.yml
name: Deploy via Teleport
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Login to Teleport
        run: |
          tsh login --proxy=${{ secrets.TELEPORT_PROXY }} --token=${{ secrets.TELEPORT_TOKEN }}
      - name: Deploy to VPS
        run: |
          tsh ssh deploy@vps-01 "cd /app && git pull && docker-compose up -d"

Slack/DingTalk Alert Integration

Automatically alert on suspicious logins:

# Enable alerts in Teleport configuration
teleport yaml set /services/alerts/notifications - '{
  "method": "webhook",
  "endpoint": "https://hooks.slack.com/services/xxx",
  "events": ["session.start", "auth.failure"]
}'

Prometheus Monitoring Integration

Teleport exposes standard metrics endpoints:

# prometheus scrape config
scrape_configs:
  - job_name: 'teleport'
    static_configs:
      - targets: ['your-domain.com:3000']

Key metrics:

• teleport_auth_requests_total: Total authentication requests
• teleport_sessions_active: Currently active sessions
• teleport_proxy_connections_total: Proxy connection count

Cost Analysis

Teleport’s open-source edition (USM - Universal Security Mesh) is completely free with no feature limits on core capabilities:

For individual developers and small-to-medium teams, the open-source edition is more than sufficient. The enterprise edition mainly enhances SCIM integration, remote audit log storage, and AI-assisted analysis.

Migration Guide: From SSH to Teleport

Gradual Migration Strategy

No need to switch all at once — Teleport supports hybrid mode:

Phase 1: Parallel Operation
  · Keep existing SSH access
  · New servers managed via Teleport
  · Gradually migrate old servers

Phase 2: Progressive Switch
  · Migrate core servers first
  · Configure RBAC in Teleport
  · Disable direct SSH on some servers

Phase 3: Full Migration
  · All servers accessed through Teleport
  · Close port 22 on firewalls
  · Revoke all old SSH keys

Migration Checklist

• Backup all existing SSH keys and authorized_keys lists
• Create RBAC roles in Teleport matching existing permissions
• Migrate servers one by one, verify Teleport access before disabling direct SSH
• Revoke all old SSH keys
• Close port 22 on server firewalls (allow only Teleport Proxy)
• Configure session recording and audit alerts
• Train team members to use tsh commands

Summary

Teleport solves a core problem every VPS operator faces: how to securely and controllably access multiple servers.

It replaces traditional SSH key management with three key innovations:

1. Short-lived certificates: Access permissions auto-expire, eliminating the risk of a single key working forever;
2. RBAC permissions: Evolved from “who can login” to “who can login as what identity to which machines and do what”;
3. Complete audit trail: Every session has recording and command logs, making security incidents traceable.

Deploying Teleport requires no changes to your existing server architecture — it works above the SSH protocol layer, transparently taking over access control. Start today and upgrade your VPS access from “key management” to “zero-trust security”.

References

• Teleport Official Documentation
• Teleport GitHub Repository
• RBAC Role Configuration Guide
• Session Audit and Playback
• Self-Hosted Teleport Cluster Best Practices