Secure your Linux servers with Teleport, a modern Zero Trust access platform that provides a more secure alternative to traditional SSH access. In this hands-on tutorial, you’ll learn how to install Teleport, configure a Teleport control plane, enroll Ubuntu servers, and securely connect to your infrastructure through both the web interface and the Teleport client.

Thanks to Teleport for sponsoring this tutorial! Check out Teleport and secure your Linux servers with a modern Zero Trust access platform that provides a more secure alternative to traditional SSH access.

Getting Started with Teleport

Before we start deploying Teleport, let’s take a closer look at what it actually is—and perhaps more importantly, why it exists in the first place. Is there really anything wrong with plain old SSH?

The short answer is no.

OpenSSH has earned its reputation as the industry standard for remotely managing Linux servers because it’s mature, secure, and extremely reliable. When properly configured, it’s an excellent solution.

One of the first security best practices administrators typically implement is disabling password authentication in favor of public key authentication. If you’re new to SSH keys, I’ve covered that topic in previous videos.

The interesting thing is that SSH keys aren’t the problem either. In fact, they’re a very secure way to authenticate. The real challenge is managing access over time.

As infrastructure grows, so does the number of servers, administrators, contractors, and automation systems that need access. Before long, keeping track of who has access to what, onboarding new users, removing old ones, rotating credentials, and auditing activity can become a significant administrative burden. And let’s be honest—administrators are busy people. The more moving pieces there are, the easier it becomes for something to be overlooked.

For example, it’s not uncommon to find authorized SSH keys that belong to employees who left months ago. Or imagine needing to revoke a compromised SSH key from hundreds of servers. Even if you have good documentation and automation, that’s still something you need to coordinate and verify.

Those are exactly the kinds of problems Teleport was designed to solve.

Teleport doesn’t replace SSH—it builds on top of it. Instead of managing authentication independently on every server, Teleport centralizes authentication, authorization, and auditing. Administrators define access policies in one place, and Teleport enforces them consistently across the infrastructure.

With traditional SSH, your SSH client connects directly to an SSH server running on the destination machine. That server authenticates you and, assuming everything checks out, provides you with a shell.

With Teleport, there’s an additional step. Instead of authenticating directly with each individual server, you authenticate with your Teleport cluster first. Teleport verifies your identity, determines which resources you’re authorized to access, and then securely connects you to the destination server.

Another important difference is how authentication is handled. Rather than relying on long-lived SSH keys that must be distributed and managed across your servers, Teleport acts as its own certificate authority and issues short-lived SSH certificates after you’ve successfully authenticated. That greatly simplifies key management while reducing the risks associated with long-lived credentials.

Although today’s tutorial focuses on SSH, Teleport is capable of much more. It can also manage secure access to Kubernetes clusters, databases, web applications, Windows desktops, and other infrastructure resources. Those are all interesting topics in their own right, but they’re outside the scope of this project. Today, we’re going to focus on building a Teleport cluster and using it to securely manage SSH access to Linux servers.

Setting Up the Lab Environment

Continuing on, I think the best way to learn any technology is to actually build it yourself. Reading documentation is important, but there’s no substitute for seeing something in action and getting some hands-on experience. That’s exactly what we’re going to do next.

Before we start installing anything, let’s take a quick look at the lab environment we’ll be building, along with what you’ll need if you’d like to follow along.

At the center of everything is our Teleport server. This server hosts our Teleport cluster and becomes the central point for authentication, authorization, and access management. Every connection we’ll make during this tutorial will first be authenticated through the Teleport cluster before access to any managed resource is granted.

For this tutorial, I’ll be deploying the Teleport server on a Linode VPS, but that’s simply for convenience. You can just as easily self-host it on a virtual machine, a physical server, or another cloud provider.

Next, I have a Linux server that will act as our target machine. This represents the infrastructure we’re trying to manage. We’ll install the Teleport agent on this server, enroll it into our Teleport cluster as a node, and then securely connect to it later in the video.

Finally, I have a third Linux instance that will act as my client. In a real-world deployment, this would typically be your workstation or laptop—the machine you use to manage your infrastructure. I’m using another Linux server simply to make the demonstration easier to reproduce, but Teleport clients are also available for macOS and Windows. Since Learn Linux TV focuses primarily on Linux, that’s what we’ll be using throughout this tutorial.

So, for this lab, we’ll be working with three Linux systems:

• A Teleport server that hosts our Teleport cluster.
• A Linux node that we’ll manage through Teleport.
• A Linux client that we’ll use to connect to that node.

As your environment grows, you’ll simply continue enrolling additional servers into your Teleport cluster, allowing them to be managed through the same centralized platform.

One final note before we begin: whenever I deploy a brand-new Linux server, there are several initial setup tasks I always perform first, such as installing updates, configuring the hostname, and taking care of a few basic security hardening steps. Rather than repeat all of that here, I’ve already created a dedicated video that walks through those best practices. If you’re starting with a fresh Linux installation, I’d definitely recommend watching that first. For the sake of keeping this tutorial focused on Teleport, I’ll assume those initial setup tasks have already been completed.

Installing and Configuring Teleport

Now it’s time to start building our Teleport cluster.

I’ve already completed the initial server hardening and setup that I mentioned earlier, so we can jump straight into installing Teleport itself. We’ll begin by setting up the Teleport control plane on our dedicated Teleport server.

In a production deployment, the control plane is responsible for authentication, authorization, and routing client connections to the appropriate resources. For this lab, we’ll be running the Auth Service and Proxy Service together on a single server, which is a great fit for homelabs, testing, and smaller environments.

There are several ways you can deploy Teleport. You can use Teleport Cloud, build it from source if that’s your preference, or self-host it on your own infrastructure using Teleport’s official installation script. That’s the approach we’ll take today.

Before we install anything, though, we need to take care of one important prerequisite: DNS.

For the deployment we’re building in this tutorial, Teleport will automatically obtain a trusted TLS certificate from Let’s Encrypt. That means we’ll need a public domain name that resolves to our Teleport server before continuing.

Exactly how you register a domain and manage DNS records depends on your registrar or DNS provider, but the overall workflow is the same regardless of who you’re using.

For this demonstration, I’m using the learnlinux.cloud domain, which I already own. I’ve created two DNS records that both point to the public IP address of my Teleport server:

teleport.learnlinux.cloud
*.teleport.learnlinux.cloud

The first record is used to access the Teleport cluster itself, while the wildcard record allows Teleport to expose additional resources under the same domain when needed.

If you’re following along, don’t continue until your DNS records have fully propagated. One easy way to verify that is with the dig command:

dig @8.8.8.8 teleport.learnlinux.cloud

If the IP address returned matches your Teleport server, you’re ready to move on.

One additional requirement is that your Teleport server must be reachable on TCP port 443. Let’s Encrypt needs to verify ownership of your domain before issuing a certificate, so if a firewall blocks HTTPS traffic, certificate issuance will fail.

Once DNS is working, installing Teleport is surprisingly simple. We only need to run the official installation script:

curl https://cdn.teleport.dev/install.sh | bash -s 18.9.1

That’s all it takes to install the software.

Next, we’ll generate a basic configuration for our Teleport cluster:

sudo teleport configure -o file \
  --acme \
  --acme-email=jay@mydomain.com \
  --cluster-name=teleport.learnlinux.cloud

Here I’m enabling automatic certificate management with Let’s Encrypt, providing an email address for certificate notifications, and specifying the hostname that identifies my Teleport cluster.

Once the configuration has been generated, we’ll enable and start the Teleport service:

sudo systemctl enable --now teleport

After a few moments, the Teleport web interface should be available at:

https://teleport.learnlinux.cloud

If you browse there immediately, you’ll notice it’s asking you to log in—but we haven’t created our first administrator account yet.

To do that, we’ll return to the terminal and create our initial Teleport user:

sudo tctl users add teleport-admin \
  --roles=editor,access,auditor \
  --logins=jay

This command creates a Teleport user with administrative privileges and generates a one-time enrollment URL. Open that URL in your browser, choose a strong password, complete the enrollment process, and you’ll be ready to sign in to your brand-new Teleport cluster.

Adding a Node

At this point, our Teleport cluster is up and running—but it isn’t managing any infrastructure yet. The next step is to enroll one of our Linux servers as a Teleport node.

To do that, click Enroll a New Resource. Since my target server is running Ubuntu, I’ll search for Ubuntu and select it from the list.

Teleport will now generate a one-time installation command. We’ll simply copy that command and run it on the Ubuntu server we want to manage.

The command installs the Teleport agent, securely enrolls the server into our Teleport cluster, and configures it to communicate with the Teleport control plane. It will look something like this:

sudo bash -c "$(curl -fsSL https://teleport.learnlinux.cloud/scripts/bf9482abbeb09688765d884cbf658df5/install-node.sh)"

After the installation completes, return to the Teleport web interface. Within a few seconds, the new node should automatically appear. We can click Next to complete the enrollment wizard, and Teleport even gives us the option of opening a browser-based terminal to verify that everything is working correctly.

Although that’s a handy feature, we’ll be focusing primarily on command-line access throughout the rest of this tutorial.

Now there’s one more thing we should do before we continue.

Earlier, we created an administrative Teleport user so we could configure our cluster. For day-to-day administration, though, it’s generally a better idea to use a standard Teleport user with only the permissions it needs.

It’s also important to remember that Teleport users and Linux users are two different things. A Teleport user represents your identity within the Teleport cluster and determines what resources you’re allowed to access. That user can then be mapped to one or more Linux accounts on your managed servers.

Since my Linux username is jay, I’ll create a Teleport user with the same name. On the Teleport server, I’ll run:

sudo tctl users add jay --roles=access

Teleport will generate a one-time enrollment URL. I’ll open that link, set a password, and complete the enrollment process. Once that’s done, I’ll have a standard Teleport user that I’ll use for SSH access throughout the remainder of this tutorial, while reserving my administrator account for cluster management tasks.

Connecting from a Client

So far, we’ve built our Teleport cluster and enrolled an Ubuntu server as a Teleport node. Now it’s time to use it.

Ultimately, that’s the entire goal: securely connecting to and managing our infrastructure. So let’s switch perspectives and see what the workflow looks like from an administrator’s point of view.

For this demonstration, I’ll be using another Linux system to represent my workstation. Unlike the Ubuntu server we enrolled earlier, this machine doesn’t need to become a managed Teleport node. Since it’s simply acting as the administrator’s workstation, all we need to do is install the Teleport client.

Once the Teleport client is installed, the first step is authenticating with our Teleport cluster. Remember, with Teleport you don’t authenticate directly with each individual server. Instead, you authenticate with the Teleport cluster first, which verifies your identity and determines which resources you’re allowed to access.

To do that, run:

tsh login --proxy=teleport.learnlinux.cloud

After logging in, connecting to one of our managed servers is just as straightforward:

tsh ssh jay@ubuntu-server.learnlinux.cloud

And just like that, we’re connected.

Behind the scenes, Teleport authenticated us, verified that we’re authorized to access this node, issued a short-lived SSH certificate, and established the SSH session for us. From the administrator’s perspective, the experience feels very similar to using SSH directly—but with centralized authentication, authorization, and auditing.

If you prefer, you can also launch terminal sessions directly from the Teleport web interface, which can be especially convenient when you’re already working in the browser.

Although this tutorial focused specifically on SSH access, we’ve really only scratched the surface of what Teleport can do. It also provides secure access to Kubernetes clusters, databases, web applications, Windows desktops, and many other types of infrastructure. There are also additional capabilities such as Zero Trust Access, Identity Governance, session recording, and auditing that we didn’t have time to cover today.

But at this point, we’ve accomplished exactly what we set out to do. We’ve built a self-hosted Teleport cluster, enrolled Linux servers as Teleport nodes, created users, and securely connected to our infrastructure using Teleport. From here, you can continue expanding your cluster simply by enrolling additional resources as your environment grows.