Replacing Teleport on a Budget

Antoine Pultier — 2025-09-15

Teleport is a software tool to provide secure access to SSH servers, Kubernetes clusters, databases, and web apps. It makes life of system administrators slightly easier. Teleport also has a set of features for people loving audit logs, and companies having strict and cumbersome compliance requirements.

I will explain how I replaced Teleport in the infrastructure I manage at work, while keeping most of its features, with open-source and affordable tools.

Quick Navigation

Teleport is Still Open-source, but…

From version 16, Teleport changed its terms of use, which prevent large companies from using the open-source compiled version. One has to compile everything themselves, or buy a licence. Fair enough. I only need a few users and not so many servers, but the company is large.

Unfortunately, after some discussions with the Teleport sales team, it appears that I’m priced out and that Teleport is targeting enterprise customers. So, I can compile everything myself and distribute the binaries to the users, which is a lot of boring work making Teleport not worth it to me, or I can look for alternatives.

The Perfect Teleport Alternative Does Not Exist

I wasted some time looking for a good alternative to Teleport, but my conclusion is that nothing is as good yet (September 2025). The main Teleport alternative is StrongDM, that is proprietary and “contact sales” priced. I didn’t test it.

Please correct me, because I would love to hear about a good alternative. I reached a stage that when I look for alternatives, I find my old posts discussing alternatives to Teleport on Reddit or Hacker News.

However, I found that you can replace most of the Teleport features with a combination of open-source tools, and some compromises. And it can be better in some ways.

NetBird for Network Access

To provide secure connectivity to the infrastructure, I decided to use NetBird, an open-source WireGuard-based VPN solution.

NetBird is a lot more than a reverse tunnel solution like Teleport does for network access. A mesh VPN is more complex, and I tend to avoid too much complexity, but it also has a better architecture as it does point-to-point connections whenever possible. It is faster than Teleport by design. Teleport has been a limiting factor when transferring big data.

While it’s possible to self-host NetBird, the managed service’s pricing makes sense for small teams. Also, the company is German.

Moreover, NetBird isn’t limited to only GitHub as an identity provider. Teleport Open-source only supports GitHub and locks other identity providers to the Enterprise edition. Using GitHub accounts to manage access to the infrastructure was a bit annoying, though not the end of the world in my case, but I’m happy to use my company identity provider now.

An alternative to NetBird is Tailscale, or the self-hostable Open-source version Headscale.

OpenSSH for SSH Access

To replace Teleport SSH, I’m going back to the classic OpenSSH. When the scary XZ utils backdoor was discovered, I was full of myself as my infrastructure wasn’t using OpenSSH written in C, but Teleport written in Golang. Not Rust, but still. But after all, OpenSSH is a mature and solid solution worth the security risks of being written in C.

Nevertheless, I used the DevSec SSH Hardening Ansible Role to harden the SSH configuration a bit. And OpenSSH is not exposed to the internet, only to the NetBird network.

Going back to OpenSSH has been a small relief. Teleport has been annoying to use for users, as it requires either a different tsh client to install, in version 15, and a bunch of boring configurations and other tsh proxy ssh commands.

By the way, NetBird provides an SSH server, but it seems to be a minimal last resort solution that is not something to rely on for normal SSH usage.

GitLab for SSH Key Management

Proper authentication shouldn’t rely on passwords. Passwords can leak, are usually weak, are a pain to manage, and we can forget them.

Another key feature of Teleport is the automatic management of SSH keys, that are short-lived. Short-lived keys is a very nice to have feature from a security point of view. However, these short-lived keys are not a must in my case. Most of the security relies on NetBird that requires a recent authentication with MFA. I see the advantage of short-lived keys, but the added complexity doesn’t seem worth it in my case. And it’s not a security requirement.

Users are used to upload their long-lived SSH public keys somewhere and have them automatically propagated to the servers. That’s how most of the research HPCs work, and also how many public cloud providers operate.

I looked for the simplest solution to let users manage their own SSH keys, and I settled on GitLab. My company has an internal GitLab instance and I can fetch the keys from there.

In case you don’t know, SSH keys are publicly available on GitHub and GitLab. For example:

# public github
curl https://github.com/defunkt.keys

# or public gitlab
curl https://gitlab.com/dzaporozhets.keys

# or internal gitlab
curl https://gitlab.example.net/username.keys

I found a small script to tell sshd to fetch the keys from GitLab, using the AuthorizedKeysCommand directive: ssh-getkey-gitlab.

I modified it slightly, but it works well, and it’s simple. Most users already maintain their SSH public keys in GitLab, so it just works for them. The script can also work the same with GitHub or any HTTPS endpoint, despite its name. Don’t use this without TLS of course, and you must trust the key server.

SmallStep SSH is regularly mentioned as an alternative to the Teleport SSH key management feature, but I didn’t like it. The documentation wasn’t up-to-date and split in various places, the open-source deployment felt like a set of proof-of-concepts, I had to analyse and debug random scripts. I managed to get it working once on a set of VMs, but I never managed to do it again. It has been very frustrating. It’s probably a skill issue, but I won’t recommend it unless you like sysadmin challenges. I am sure the managed product is better, but I decided to stop bothering with “contact us” prices.

I also decided to ignore OpenSSH’s Kerberos support, as it seems to be hell.

No more SSH Session Recordings

While it is possible to find SSH servers supporting session recording, I decided to skip this feature. This was a cool feature that I never used in practice.

It sounds like tlog could be a good alternative to this feature, but I didn’t try it. If you only want to record your terminal session to share what you did, you can also use asciinema.

Moreover, the session recording feature may be useful for auditing and checking what users did in case something bad happens, but I don’t like to spy on users like this. And since we sometimes manipulate sensitive data, it makes the recordings sensitive as well.

Additionally, Teleport only records the terminal and not the network connections through port forwards or SOCKS5 proxying offered by SSH, and the SCP and SFTP file transfers. We often use Ansible with SSH and the recordings would be useless in this case as Ansible transfers files and runs commands in a non-interactive way. If you must record your users for some reason, perhaps force them to use a machine that is fully recorded. Teleport doesn’t record everything.

Kubernetes Access with NetBird and OpenID Connect

Accessing the Kubernetes API servers is done through NetBird.

To manage the authentication, the most straightforward solution I identified is the kubectl oidc-login plugin: int128/kubelogin. It’s based on OpenID Connect (OIDC) and therefore supports many identity providers.

Authorization is managed through Kubernetes as usual. It’s simpler than Teleport because it doesn’t rely on impersonating users and groups. With the oidc-login, you get the usernames and groups from the identity provider, and you can create the Kubernetes Roles, RoleBindings, ClusterRoles, and ClusterRoleBindings accordingly.

Teleport was also recording the kubectl exec interactive sessions, like SSH sessions, and I don’t have a replacement for this feature. Since kubectl port-forward and kubectl cp were not recorded by Teleport, I don’t see a major difference there. My arguments are the same as for SSH session recordings.

Databases Access: Back to Basics

I only used the database access feature of Teleport once, and some users described it as annoying. So I decided to skip this feature with the other database deployments and stick with classic username/password or TLS client certificates.

It’s use-case specific, but in my infrastructure, users needing database access are always the database administrators. The Teleport feature to record SQL queries and verify authorization is therefore not needed.

I’m not sure if there is a good replacement to this feature for all the many databases supported by Teleport. Though I’m not convinced of the value of this feature in practice, except for compliance reasons.

Web Apps Access with OAuth2 Proxy

I never used the web apps proxying feature in Teleport, as I find OAuth2 Proxy to be a better solution. It’s more user-friendly, it’s free, and it’s open-source.

Centralized Logging

Teleport was great at being the central access point to the infrastructure, with all the access logs in one place. Now, the network logs are in NetBird, the SSH logs are in the various servers, same with Kubernetes access logs and so on.

If you want to centralize the logs, the ELK Stack is a classic solution. It might be worth having it in your infrastructure even if you use Teleport, as Teleport doesn’t collect all the logs.

Access Control Rules

Teleport had a role based access control system, through YAML, linked to GitHub groups. That was fine. The new system is a bit more fragmented, but it’s also simpler and closer to the Unix and Kubernetes way of doing things.

NetBird has its access control policies, with a graph view control panel that is simply great to understand and manage who can access what.

The SSH access control is managed through Ansible and Unix usernames and groups. Old school, but simple and effective. We already managed Unix usernames and groups like this before. Teleport could create “ephemeral” Unix users on the fly, but if you want persistent users with some specific configuration, you have to manage them anyway.

Kubernetes access control is managed through Kubernetes RBAC, using the usernames and the groups coming from the identity provider.

Final Cost

Setting this up and maintaining it takes some effort. It took me about 2 days of work to set it up, test it, and write the documentation. I expect the system to require some maintenance, a few hours there and then, but this should go relatively smoothly. Teleport also required a little maintenance.

Is such a setup worth it over Teleport? 2 days of work is a few orders of magnitude cheaper than the Teleport Enterprise licence I was quoted, so in my case yes. But if your infrastructure fits within the free tier of Teleport, for the foreseeable future, and you don’t mind the GitHub-only authentication, then Teleport has a good value proposition.

Is automating the SSH keys management, the Kubernetes credentials, the network access, and so on, worth it? I usually follow the XKCD #1205 - Is It Worth The Time? guidelines. I think it is worth it because it saves a lot of context switching.

If you don’t have money problems, I think this document can be a good selling point for Teleport Enterprise. If you like to fiddle with sysadmin stuff, have a limited budget, and aren’t required to use enterprise-grade software, then I think this setup can be a good alternative.