Moving Beyond Static SSH Keys with Teleport Certificates

The Liability of the Static SSH Key

Managing static SSH keys across a growing fleet of servers is a security liability. When a developer leaves a company or a laptop is compromised, the static private key remains valid until every single authorized_keys file across the infrastructure is manually updated. This "key sprawl" makes rotation nearly impossible and auditing a nightmare.

The solution is to shift from a key-based identity model to a certificate-based model. Teleport implements this by acting as a Certificate Authority (CA), issuing short-lived X.509 certificates that expire automatically, removing the need to manage individual public keys on target nodes.

How the Teleport Access Plane Works

In a traditional setup, the server trusts a specific key. In Teleport, the server trusts the Teleport Auth Server. This shift changes the authentication flow entirely:

• Identity Integration: Users authenticate via an Identity Provider (IdP) using OIDC (OpenID Connect). This ensures that if a user is deactivated in the corporate directory, their ability to request SSH certificates vanishes instantly.
• Short-Lived Certificates: Upon successful login, the Teleport Auth server issues a certificate. This certificate is valid for a limited window (e.g., 8 to 12 hours). Once it expires, the user must re-authenticate.
• Embedded RBAC: Role-Based Access Control (RBAC) is baked into the certificate. The certificate tells the target node exactly which Unix user the requester is allowed to impersonate (e.g., ubuntu or root).

Implementing the Trust Relationship

For a target node to accept these certificates, it must be configured to trust the Teleport CA. This is handled during the node join process, which modifies the system's SSH configuration.

Configuration Example

When a node joins a Teleport cluster, the Teleport agent updates the /etc/ssh/sshd_config file. To verify the trust relationship manually on a Linux node, check for the TrustedUserCAKeys directive:

# Run this on the target node as root or with sudo
sudo grep "TrustedUserCAKeys" /etc/ssh/sshd_config

Expected Result: You should see a line pointing to the Teleport CA public key file, typically located at /var/lib/teleport/ssh_ca.pub.

To initiate a session from a local workstation, the user runs the following command (assuming the tsh client is installed):

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

After completing the browser-based SSO flow, tsh stores the short-lived certificate in the local profile. You can then connect to a node without providing a password or a static key:

tsh ssh user@node-name

Operational Trade-offs and Limitations

While certificates solve the key rotation problem, they introduce new dependencies:

• Clock Synchronization: Because certificates have a strict NotBefore and NotAfter timestamp, clock skew is a critical failure point. If the target node's system clock drifts significantly from the Auth server, valid certificates will be rejected as "not yet valid" or "expired."
• Auth Server Availability: The Auth server is the heart of the system. If it goes offline, no new certificates can be issued. While existing sessions remain active, new logins are blocked. For production environments, the Auth server must be deployed in a High Availability (HA) cluster.
• Initial Migration: Transitioning a legacy fleet requires updating sshd_config on every machine. This can be disruptive if not automated via configuration management tools like Ansible or Terraform.

Verifying the Security Posture

To ensure the system is operating as intended, perform these three checks:

1. Certificate Expiry: Run tsh status to see the remaining lifetime of your current certificate. Verify it matches your organization's TTL (Time To Live) policy.
2. Audit Trail: Access the Teleport Web UI or use tsh play to view session recordings. Since the Proxy intercepts the traffic, you can verify that TTY output is being captured without needing to install auditing software on the target host.
3. Access Denial: Attempt to log in with a user account that has no assigned Teleport role. The Auth server should refuse to issue a certificate, preventing any connection attempt from even reaching the target node.