Secure Remote Access with Secretless SSH Access - overview

Teleport's Infrastructure Access Platform is a highly adaptable solution that addresses various use cases. It enables secretless SSH access to any internet-connected device, making it ideal for solving compliance requirements and enhancing infrastructure access security. Watch this session as we explore Teleport as a secure secretless solution for accessing remote Linux infrastructure via SSH. In particular session, we will focus on its application in providing remote support within client environments, a common need for Managed Service Providers (MSPs). This episode covers:

Key topics on Secure Remote Access with Secretless SSH Access

A Teleport cluster is a collection of components which consists of a Teleport proxy, a Teleport Auth Service along with Teleport nodes, and resources that connect to it.

With Teleport, you can remotely access the infrastructure that's under your management as a managed service provider (MSP).

The Teleport Auth Service manages certificates for things like infrastructure nodes, users, SAML, OIDC.

Teleport connectivity modes include direct connectivity and IoT connectivity.

A Trusted Cluster is a remote Teleport cluster joined to your own cluster via a trust relationship.

Teleport's event and auditing system provides a detailed look into who is doing what on certain resources that are connected to Teleport.

Teleport is packaged in many different ways

Expanding your knowledge on Secure Remote Access with Secretless SSH Access

Learn more about Secure Remote Access with Secretless SSH Access

Transcript - Secure Remote Access with Secretless SSH Access

 00:00:05.570 Hello, everyone. Good afternoon. Thanks for joining this webinar. Give me just a moment. I'll get everything set up here.

 00:00:35.425 All right. Welcome everybody to this webinar. Today we're going to talk about Secure Remote Access with Secretless SSH Access. My name is Travis Swientek. I'm in product marketing here at Teleport. We've got a couple of helpers with me today. We've got Katz showing up here in the chat, asking a few questions. Love to hear where you're from. So throw where you're located here in the chat. Love to hear where we have folks joining from. It's always helpful. Awesome. So we've got folks from California. California's definitely representing. I'm here in Austin, Texas, by the way. From Colorado. Nice. I'm headed out to Colorado soon. I've got a trip planned in later July. We'll get started here in just a moment. We'll give everyone a second to join. Hopefully the weather there in Colorado's a little nicer. It's 94 degrees in my backyard right now with 68% humidity. So that's about 117 degrees heat index, so it feels like 117. It's pretty hot here in Texas. Summer has definitely arrived. Belgrade, Serbia. Nice. Germany. Awesome. We have folks from across the pond. Welcome.

 00:01:48.909 Okay, let's get started. We are definitely recording this, so if we do have folks joining in late, no worries. You can watch the replay. I'm going to step through a series of slides, and then we'll go through a demo. But first I'll get started and just welcome everyone to today's webinar. So again, my name is Travis Swientek, and I'm a product marketing professional here at Teleport. We'll be talking about Secure Remote Access with Secretless SSH Access. So let's dive into it. I've been at Teleport for about three years, and in that time, I've done a lot of different things here at Teleport. But I spent most of my time in customer success and support talking to a lot of our customers. And in talking to those customers, I really learned a little bit about use cases, very unique and niche use cases that I think are actually helpful for managed service providers. So I'm going to share today my thoughts on how managed service providers or MSPs — I'm going to use the acronym MSP. That stands for managed service providers — and how they can use Teleport in a really unique way to support their customers using Teleport. With Teleport, you can remotely access that infrastructure that's under your management as an MSP.

 00:03:04.320 So let's dive further into this. But first I have just a quick message. So in the spirit of AI and all the fun stuff going on in AI and given that we only have 30 minutes together — and I plan to move very quickly in this webinar — I would like you to open a new tab in your browser. Don't go away from this one or else you'll lose the webinar. But go to goteleport.com/docs. We've embedded an amazing search and conversational AI tool that's trained on our docs. So if I say something today that you'd like more information on, use that tool to find more information about that topic. For example, we're going to talk about certificate-based authentication. So if you'd like to read more information about that, search for certificates, and you'll find plenty of documentation to help answer your question. Or if you have a specific question that you want to ask the bot, it can also have a conversation with you. It uses generative text, and it will generate a response based off our docs. So if you could use that to ask your question, that'd be really helpful for us, because we're testing that out and taking in feedback and continuing to iterate on that bot. You're also, of course, welcome to ask questions here in the Q&A box. So shoot your questions our way. If we don't get to your question, I'll shoot you an email here after this webinar and follow up with you afterwards.

 00:04:19.395 All right. Thanks for that. Let's go over to the agenda. So today we're going to look a little — we're going to take a look, rather, at how Teleport works. If you're new here, I'm only going to cover about two to three minutes on this subject. We have a ton of resources on our website that help explain Teleport, and I'd encourage you to take a look there for more detailed explanations. Next, we'll briefly talk about certificate-based authentication and its underlying structure that protects data transitioning over the internet. Then we'll dive into why I think MSP should use Teleport. I'm going to cover Teleport's connection modes along with unique features or a unique feature called Trusted Clusters. We'll take a look at session events and auditing and how that can help you confidently answer questions like, who accessed this infrastructure or maybe something we all dread hearing — how did that database table get dropped? And finally, we'll cover packaging and deployment methods so you can easily deploy Teleport into any infrastructure under your management. If we have time, I'll show you Trusted Clusters in a live demo. So with that, let's dive into it. How Teleport works in 120 seconds. We'll see if I can do that in 120, but might take a little bit longer. We'll see.

 00:05:32.435 All right. Here is a typical diagram of a Teleport cluster along with various resources that are connected to it. I'm going to be using the key terms here extensively throughout this webinar. So let's discuss them. First, we have a Teleport cluster. A Teleport cluster is a collection of components which consists of a Teleport proxy, a Teleport Auth Service along with Teleport nodes, and resources that connect to it. A Teleport cluster can be deployed in our managed Teleport cloud offering. You can deploy it yourself in your cloud. You can deploy it on-prem in your own environment. You can run all of this in a container on your laptop. I mean, I wouldn't recommend doing that in any production capacity, only for testing and development, but it is certainly possible. We have Docker containers for everything. So now let's talk about Teleport proxy. I've highlighted it in red here in the diagram. The proxy component — it acts as a front end and primary ingress and egress for all Teleport traffic when you're communicating to a Teleport-connected resource. When you're interacting with our command line tool called tsh, you are accessing the Teleport proxy or perhaps our Teleport web interface. Of course, you're connecting to the proxy there. Similarly, all of your Teleport node resources, the things on the right-hand side of this diagram — those are all connected to the Teleport proxy as well. So with everything connected to the proxy, of course — well, we'll talk a little bit more about that.

 00:07:00.113 But let's talk about the auth server, and then we'll get back to Teleport proxy. I've highlighted the auth server here. The auth server component acts as sort of the brains of the operation. It maintains users, roles, audit events. It issues certificates and a lot more. This resource is not accessible by users, and it's really only used by Teleport internally. It connects to a database. It can use a SQLite local database for non-production, for production. When you're deployed out to AWS, you want to use something like DynamoDB. Lastly, we have Teleport node resources. So I'm using Teleport node here, but I'm also saying resources in addition to that. Just to add a little bit more context to that term. So Teleport node resources, it's simply your infrastructure. That could be a Linux or Windows server, a Postgres database, web apps, and Kubernetes clusters. All right. Let's add users to this diagram. So users in this situation are sitting on a public network. Maybe they're at Starbucks, maybe they're in their home. They're not located within the same network or VPC or data center as your Teleport cluster. They're outside. And they are accessing the Teleport cluster over the internet, and they're connecting to that proxy. So again, want to point out here that everything is connecting to the proxy. The proxy is sort of the central component of where everything connects.

 00:08:29.913 Now let's add one more thing to this diagram, another data center. So most folks have multiple data centers. They have multiple deployments of infrastructure all over the world. Maybe it's on-prem and cloud. You can have all of your infrastructure, regardless of where it's at, connected to Teleport. So here I have another private network of Teleport resources. Notice though that there is not a Teleport cluster running inside of that private network. It's just Teleport nodes, and keep that bookmarked in your mind as we continue on. All right. Next, let's talk about PKI certificates. All right. Now, given that Teleport is a certificate-based tool, your next question is probably like, how do we use certificates across Teleport? We need to talk briefly about certificates and the underlying PKI infrastructure — how all of that works. But put simply, PKI is a framework that enables a secure transmittal of information using certificates. PKI establishes a certificate authority role. The certificate authority signs and publishes public keys. In our case, the Teleport auth server is assigned the role of certificate authority. The Teleport Auth Service is busy managing certificates. That is its primary goal. It manages certificates for things like infrastructure nodes, users, SAML, OIDC. Anything that uses TLS encryption or certificates to communicate — the auth server has a hand in generating that certificate and issuing it.

 00:10:07.234 So anytime a node initially connects to a Teleport cluster, a series of handshakes has to take place in order to establish the underlying connection, the SSH connection, between the infrastructure that you're connecting to the proxy server. So this sort of handshake occurs between, say, a Linux server and the Teleport proxy and auth server to generate these certificates. And then an SSH tunnel is generated, and these resources then connect to the Teleport proxy using that secured tunnel. Additionally, when users connect or log in to the Teleport proxy, they do `tsh login` or come to the Teleport web UI and log in, the Teleport Auth Service is going to generate a series of certificates. And these certificates are used for establishing connection to resources. So if I want to SSH into a Linux server, I will use that certificate in order to connect. We store traits about users as well inside of certificates. So traits include things like role-based access controls, principal logins, and more. So if you'd like to learn more about how Teleport implements PKI, head over to our blog. There was a really quick rundown of PKI and certificates. But we've got a ton of great information, very technical detailed blog posts that I've listed here. I believe Katz or Riley is going to throw those links down here in the chat. But go check out those blog posts. They're really interesting.

 00:11:34.328 Okay, so now that you have a basic understanding of how Teleport works, we're going to dive into connectivity modes. As we discuss the different modes, I'm going to align my expectations or rather explanations with typical managed service provider use cases. So first, let's talk about direct connectivity mode. In this diagram, we have a very simplified version of a Teleport cluster deployed onto AWS cloud. A Teleport cluster exists along with its Teleport node resources, which are located in an isolated VPC. Direct connectivity mode is really the simplest connectivity mode. It's connecting Teleport node resources directly to the Teleport cluster without traversing a public network or public internet. Keep that in mind, regardless of connectivity modes, Teleport is always using those encrypted SSH tunnels that we talked about for communication between all of the resources. So whether it's a Kubernetes cluster or database SSH, we are encasing all of those connections over SSH tunnels. This is the most common deployment method that we see. And it's used when your infrastructure footprint is really contained within a single data center region or VPC. We're not really interested in this connectivity mode for today's discussion. So we're going to move on past this.

 00:12:54.632 And next we're going to talk about IoT connectivity mode. We named this IoT because Teleport can really be installed on anything anywhere. So fun fact, if you flew on an airplane recently, Teleport is likely running onboard on the infrastructure that powers the media systems for your flight. So let's dissect this diagram just a little bit. On the left-hand side, we have a typical AWS cloud deployment. And just like the previous slide, we have internal resources within the VPC that are directly connected to the Teleport cluster. To the right of the cluster, I've added an internet gateway, which allows our Teleport cluster to be reached from the public internet. Now please note this is a very, very simplified diagram. I know it's not technically correct, but I just want to point out that the Teleport proxy here is the only thing that's exposed to the public internet. The Teleport Auth Service will not be. All right. So coming through this internet gateway, we're going to hit the Teleport proxy itself. All right. Let's give our Teleport proxy a DNS name. We'll call it cyberit.teleport.sh. And it's got a public IP address, of course. So now we can hit it from the public internet. All right. So as a user or as we'll discuss here in a moment, nodes, everything can access the Teleport proxy server from the public internet using cyberit.teleport.sh. And this is where things get interesting.

 00:14:17.448 Now, going back to the managed service provider idea, imagine we are an MSP, and we have clients. We have perhaps a client who has a factory. We have a client with a restaurant and perhaps a client that has a co-location data center facility. Each one of these locations may have compute resources that we want to manage as the MSP for our client. So in the factory, there might be internet-connected vehicles that are roaming about or internet-connected robots that are assembling things. Perhaps in a restaurant, we have POS systems that are connecting to the internet. And you see these often, digital menus, which are really neat. Those are being powered by some sort of internet-connected multimedia device that is running. It's got a minicomputer. I think I've even seen some that are Raspberry Pi based, which is running a Linux OS. Or perhaps in the co-location facility case, we have a Linux, and Windows servers that are running perhaps custom software that me, as the MSP — I have to go and manage and maintain. Maybe I need to do upgrades, maybe I need to do maintenance, backups, things like that.

 00:15:19.081 In each one of these scenarios, as an MSP, I want a backdoor to remotely access the infrastructure for those maintenance troubleshooting and monitoring tasks, but that backdoor has to be secure. You can't just open the public network or open the network to the public. That would be really insecure, right? So this sort of backdoor access needs to be inaccessible from the public internet. So with Teleport’s IoT connectivity mode, you can install a Teleport node agent on the devices themselves. So if these robots are running perhaps a Linux-based system, you can install Teleport onto that. If you've got multimedia devices like a Raspberry Pi or something a little more advanced that's powering digital billboards, you can install Teleport on that. Or if you have none of that, well, you can just take a Raspberry Pi and stick it on the network. Or instead of hacker mentality here, an actual server, install that locally at the site, install Teleport there. And if you ssh into that Teleport SSH node, then you have access to the local network because that device is sitting on the local network.

 00:16:28.065 So with Teleport nodes using IoT connectivity mode, the node agent reaches outbound to the public internet via the hostname cyberit.teleport.sh. I've kind of highlighted that in red as best as I could here. There's really no firewall changes that need to occur at the factory, restaurant, or colo facility because this is all outbound traffic. So when you install the Teleport node at the factory or restaurant, it's going to reach out over the public internet and establish that reverse SSH tunnel, which allows us to then access those resources. So now with this tunnel established, you as the MSP can connect to your Teleport cluster, which is right here in the middle, and access the remote Teleport node that might be sitting at the factory, restaurant, or colo facility, just like a traditional VPN, but you are not having to manage and maintain a VPN. So you can take this idea of IoT connectivity along with all the power of Teleport and extend it to your client. So maybe your client wants to use Teleport or they're already using Teleport, they have a Teleport cluster deployed — this is a perfect use case for Teleport’s Trusted Clusters. And we actually have a ton of customers doing this today, and I find it to be the most fascinating use case. So that's why I want to tell you about it.

 00:17:41.880 So Trusted Clusters, it allows two or more independent Teleport clusters to establish trust between the two. So with this feature, there's two new terms that we need to talk about. One is root cluster and two is leaf cluster, both a roof — excuse me, roof. Root and leaf clusters are fully independent Teleport clusters, but a root cluster access — sort of that highest level entry point. So in this diagram, I've got the root cluster at the top. Now if I want to log into a leaf cluster, I can do so. Remember it's an independent Teleport cluster. But if I log into the root cluster because trust is established, I can access all of the leaf cluster resources. All right. So with this feature, let's talk — well, actually let's take a look at our previous deployment first here. With Teleport clusters at each location, as I've sort of highlighted here — so this is a previous diagram that we were looking at with the factory, restaurant, colo facility. But now I've added a Teleport cluster at each site. So on the left, again, everything's the same. At each one of these client sites, they're running a Teleport auth and proxy server, and the nodes such as the robot, the digital menus, and all of those things are connecting to that leaf cluster Teleport instance that's running locally at the site.

 00:19:00.299 Okay. So these onsite and remote Teleport clusters give the client the ability to easily access their own infrastructure just like you can as the MSP. However, as the MSP, you want that backdoor, and now you have it. So if you want to access and maintain the robots, the digital menus, the servers at that client location, Trusted Clusters allow you to do that because you've established the trust between the two clusters that you have running. So as the MSP, you've got your root cluster here on the left-hand side, and on the right-hand side, you have your leaf clusters, and trust is established between the two. And repeating, just again, sorry if I'm beating a dead horse, but on the right-hand side with the leaf clusters, those are independent clusters. So the factory — they have full access to their Teleport cluster, and they can manage their own resources. They can log into that cluster as a Teleport user and access all the resources that they need to. And then you as the MSP can jump into that same Teleport cluster by coming through your route and accessing the leaf cluster resources to help them out whenever they need help.

 00:20:03.210 So how does this work? So with IoT connectivity mode, as we discussed before, this extends to Teleport cluster — excuse me, Trusted Clusters as well. So just like a remote Teleport node resource can connect back to the Teleport cluster proxy server, the leaf clusters can use the same connectivity method and establish that persistent connection back to the root Teleport cluster. And with this connection established, logging into the root cluster lets you access the leaf cluster's connected resources. I'll show you a demo of that here in a little bit. Do note, just want to make a few notes here because I'm omitting some information that's probably very important that you're concerned with, that is role-based access controls. Role-based access controls can be used to limit who has access to what resources along with what actions they can perform. So when connecting to a leaf cluster from the root cluster, you have role mappings that are defined to limit the amount of access someone may have or what they can actually do on the infrastructure. Also note that when trust is established between the root and leaf cluster, access is one way. It's a one-way path. So as a user logging into the root cluster, you may be able to access the leaf cluster resources, but the reverse is not true. It is impossible for a user connected to a leaf cluster who is logged into the leaf cluster to then go upstream and access the root cluster. It's not possible to do that. So this characteristic makes it a really great feature for MSPs where you as the MSP — you want access to your client infrastructure, but you don't want your clients to access other client infrastructure, right? We don't want that to happen.

 00:21:40.211 All right. The last — whoop. The last bit is session events and auditing. So let's quickly talk about this. As an MSP, you have multiple systems engineers or technicians who will likely be accessing client infrastructure. Teleport's event and auditing system provides a really detailed look into who is doing what on certain resources that are connected to Teleport. So perhaps you have a technician here. I've got a couple of examples in the diagram here. First one is named Morgan. So she's connecting to web node two. Teleport will log that action when she logs in, and it'll record every single keystroke that she's doing on that machine. And with this session recording, Morgan can now take that and share it with her peers to teach them how to perform that same maintenance on those web nodes. Maybe she's doing something with an Nginx config or adjusting a Flask API server or something like that. All of that's being recorded. She could replay that back to another technician.

 00:22:36.588 Similarly, imagine our website went online due to database problems. With Teleport’s events and auditing, you can now see that Sydney accidentally dropped the user's table in production instead of staging. So I really hope there's backups there. But this gives you the good visibility of understanding what's going on. It is recording down to the SQL query level, so whatever queries are executed against the database is being logged, and you'll be able to see all of that. Now, there's far more to session events and auditing. So go check out our documentation for all the different ways you can use this feature to your advantage. You can search our docs for audit events, or you can check out the link that Riley's going to drop here in the chat. Okay. Lastly, we talked about running Teleport node agents or leaf clusters on remote infrastructure. So you probably need some way to get that software deployed out to that remote infrastructure. Well, Teleport is packaged in so many different ways, and this is not all of them. You can use Teleport's official AMIs on Amazon. You can use our RPM or Debian packages. We even have automation with Terraform as well as containers for easy deployment with a Helm chart. We've got Helm charts published in our GitHub repo. So you can deploy that out to a Kubernetes cluster. If none of these things work, know that Teleport is open source. It's written in Golang, and you can compile the Teleport binary for whatever platform where Golang tools can be installed.

 00:24:04.005 Okay, now we have about six minutes left, so I'm going to jump through a quick demo. I want to show you Trusted Clusters in action. Give me just one sec. I'm going to switch over to this tab. Okay. So here is a Teleport web interface. So this is my Teleport cloud instance. In this situation, I'm currently on the Servers tab, so I'm showing a list of all the different servers that I have connected to my Teleport cluster. I've got API nodes. I've got web nodes. I've got some applications listed here. I've got Grafana that I'm jumping into access whenever I need to run some queries against infrastructure. I've got databases connected as well. I've got my primary read, write, some standbys listed there. So me as an MSP, this is what I can see. These are all the different resources that I have for the company set up through Teleport. Now, what if I want to see my clients? I want to see the Trusted Clusters that have established trust to this root cluster. If you remember, back to our diagram, you have root and leaf clusters. We are looking at a root cluster right now. So this root cluster has access to several different leaf clusters. So from our example, we've got our factory; we've got our ice cream shop, which is a restaurant, and maybe a movie theater. So what I'm going to do is I'm going to click over to the factory. I'm going to go connect to the factory's infrastructure. And so using Trusted Clusters, again, what's happening here is the root clusters communicating over that IoT connectivity rather connection SSH tunnel that's established. And now I can see all of the factory's resources. And from there, if I want to connect to that factory resource, no problem. I can connect right from my root cluster. And let me share this tab. You can see here that I've created an SSH connection to an assembly robot that's on the assembly line right now. I can do things like htop. Well, I don't have htop. I can do top and run top on that Linux machine. I'm going back to this tab here. So back to our interface or here in the factory from the root cluster. But now what I want to show you is a leaf cluster.

 00:26:08.170 So if I'm a user in the factory or a sys admin in the factory, rather, I want to perhaps log into the Teleport leaf cluster. So here's a Teleport leaf cluster, and you'll notice I have the assembly robots that were listed from the root cluster. And so what's neat about this is since I'm directly connected to the factory, want to reemphasize that I can't go upwards. I cannot go to the root cluster here. So you'll see I only have access to the factory here because I've logged into the factory's leaf cluster. But I can connect to the assembly robot just like normal like you saw earlier, an open SSH console connection to that assembly robot. Of course — let's see. I don't know if I have any applications configured here, but if I did, they would all be listed there. Now, I mentioned audit logs and events. Let's go take a look at that real quick. So here are the audit logs. The audit logs here show the session that was started from the root cluster. So as a leaf cluster administrator, I can go in here and see who's coming in from the leaf — or excuse me, from the root cluster to access the resources that are on the leaf cluster.

 00:27:18.488 So anyhow, that is the demo. We have just a few minutes left here, so I'm going to jump into Q&A and see if you folks have any questions. If not, just want to give a plug real quick. Let me throw this tab up. If you'd like to take Teleport for a spin, we offer a 14-day free trial, no credit cards necessary. You just click the Get Started button on our website and check it out. You can spin up your own Teleport cluster, add your resources, no credit cards required. If you decide to continue using Teleport, it's only $15 per monthly active user. And that includes, I believe, 50 Teleport resources and 50,000 Teleport identity authorizations. So really good value there. If you're interested in learning more about Teleport Enterprise, hit contact sales and chat with our sales team. Let's take a look at Q&A real quick. All right. Daniel's got a great question here. Do you have any resources to convince our customers that Teleport is secure and can be trusted? Yeah, that's a good question. So there's a ton of resources on our website about how Teleport works. It's also open source. So if your customers are concerned about security, they can look at the source code itself. We also have — I believe it's trust.goteleport.com. If you go there, we have all of our certificates. We are constantly doing audits of the code. So we have a company that is constantly looking at all of the code and looking for vulnerabilities. We have a bug bounty program. We pay researchers to help us find vulnerabilities, and we patch those as quickly as we can. But yeah, there's a lot of resources out there. Check out our site and see if there's anything there that's helpful. If not, reach out to our sales team. We've got lots of resources.

 00:29:08.399 What are recommendations for handling outages with the Teleport cluster? Are there? Yeah, that's a good one. So there's break-glass procedures. So Teleport is not — it should not be used as a complete replacement for SSH. Now you should limit SSH to just a break-glass procedure. You have a SSH key that you're storing in a vault. Maybe it's an HSM. You have it offline somewhere, and you'll only use that for emergencies. But Teleport can be deployed in a highly available setup. So as you deploy Teleport, you want to make sure that you've got it deployed in a way that it's very resilient against outages. Any chance of supporting FreeBSD, pfSense? Oh, that's a good one. I don't know if I can answer that question for you, but I'll come back to you, chat with our development team. Can I integrate user identity management with a third-party tool such as HashiCorp or Peck? Yeah, there's tons of integrations. Check out our sites, scroll down, or click integrations up at the top. And there's a page for literally every integration that explains how it works. And last question here. How can I customize elements and labels when adding a new node to a cluster? That's a good question. You can do that with the node joint tokens. Okay. So we are out of time for today. Thanks, everyone, for joining. Really appreciate it. If I didn't get to your question, I'll follow up with an email. But thanks so much for attending today's webinar, and hope you all have a wonderful day. Thank you. Bye.


This session explores Teleport as a secure secretless solution for accessing remote Linux infrastructure via SSH.