How to Use Teleport with OpenSSH

Video Length: 16:03

Overview

Teleport is fully compatible with OpenSSH and can be quickly set up to record and audit all SSH activity. Teleport is a standards-compliant SSH proxy and can work in environments with existing SSH implementations, such as OpenSSH. T

This training video will cover:

  • Setting up OpenSSH recording mode
  • OpenSSH public/private key & OpenSSH cert
  • Export Teleport CA cert
  • Creating a new EC2 host to connect to
  • tctl auth sign --host
  • Importing Teleport CA and setting up /etc/ssh/ssh_config
  • Accessing OpenSSH nodes using the Teleport UI
  • Bonus: tctl auth rotate

Learn more.

Using Teleport with OpenSSH

(transcript)

Ben: Hi, I’m Ben with Teleport, and today I’ll be walking you through using Teleport with OpenSSH. This tutorial is going to focus on using sshd, which is the OpenSSH server which runs on the nodes. So if you can think of our current setup, we have Teleport node and auth and proxy already set up. You might dial back to other nodes. But you may have other nodes that you don’t want to run the node in SSH mode; you want to just use OpenSSH. And there could even be some cases — you might have a router or something that you can’t install Teleport on it, but it has OpenSSH. So you can use Teleport with any server or platform that has OpenSSH. So going through this, we have this good article on our blog, OpenSSH: the Teleport SSH.

Ben: And there’s sort of four main things that we go into. Improvised built-in server authentication. So if you saw this message before, it sort of fixes this trust on first use issue. It’s a more secure way for auditing and session control via role-based access control, and you also have better cluster introspection, and you can see all of the cluster nodes. When I go through this chore, you will see how Teleport nodes get added, but ones without them don’t get added, but you can still access them. So another thing — part of this architecture — when you do tsh ssh, it will go through the Teleport proxy, it will decrypt your message, and then pass it on to the OpenSSH server. In another tutorial, I will show you how you can use OpenSSH and agent key forwarding to work with Teleport. But we’re going to just dive in for the server side for this tutorial.

Ben: So we have a few things that support fully qualified domain names, IPv4, IPv6. And another thing is you need to turn on Teleport in OpenSSH recording proxy mode. So I already have a cluster that I’ve set up using our quick-start tutorial. I’ll have a link below for that. And here is the cluster.

Setting up OpenSSH recording mode

Ben: And so one of the first things you need to do is turn on OpenSSH recording proxy mode. And then this is done using the file config. You can see that this is the default configuration file that you get using Teleport Configure. And the one thing I’ve added is this session recording proxy, and this is going to enable the ability to use OpenSSH with recording mode. So next up, sshd needs to use the certificates generated by the Teleport user CA. So before I go too much further into this, I’m going to step back a bit and give you a little introduction into OpenSSH and public/private keys.

OpenSSH public/private key & OpenSSH cert

Ben: If you’re already familiar with OpenSSH, this is the flow that you’re probably more familiar with. You have a private key and a public key. When you deploy your fleet, you’ve got everyone’s public key on the server, and then they use their private key to gain access to it. Teleport is a next step up and uses SSH certificates. OpenSSH provides these certificates, and they have a few interesting properties: that you can only issue short-lived certificates, but these certificates in this setup also require you to set up and configure them on the node itself. So let me come back here.

Export Teleport CA cert

Ben: So one of the first things we need to do is — Teleport maintains an OpenSSH certificate. We need to export that certificate. So on the auth server we’re going to use tctl, which is the command line tool. And tctl auth export, and then it’s a --type=user > teleport_user_ca.pub. So now you can see I have teleport_user_ca.pub. I’m going to take this user_ca.pub and put this under our host.

Creating a new EC2 host to connect to

Ben: But another thing we need to do is we also need to create a host cert, which contains a list of every host which needs to be accessed. Wildcards aren’t supported by OpenSSH, and it must be a fully qualified domain name. So in my case, we need to do auth sign again and pick the fully qualified domain name or IP address of the host we’re going to connect to. So let’s fire up just a brand new AWS Linux host. So I’m just picking a small list, host available, set tags. I’m only making it available on Port 22. I’m going to launch this. And I’m going to proceed with a SSH public/private key, but we’re going to replace that with a SSH certificate. So wait for this to launch.

tctl auth sign --host

Ben: One of the things that Teleport does that OpenSSH doesn’t manage is all of these hosts. So if you’re thinking about a much larger rollout, if you add a host, you need to always auth sign to fix the case of the remote strict host checking. It is possible to turn this off. So you can turn off Proxy Checks Host to “No” and then you won’t need to perform tctl auth sign. But that does open you up to the possibility of the man-in-the-middle attack. So it is not recommended.

Ben: Okay. So this host is running. Okay. So what we need to do now is, we have– this is the fully qualified domain name of our host. So let me just put this into a scratchpad here, and we might as well also copy the IP address. So let’s go back here. We’re going to do tctl auth sign. And this is going to be under host. You need to add every host that you want to gain access to. So in my case, it’s going to be the IP address. And then we’re going to just save this out to OpenSSH cert. So we go back to the terminal post, and then you can see that we have written out these two files. We have OpenSSH host and OpenSSH cert.pub. Another pretty cool thing you can do is — you can verify the contents using SSH keygen. So you can see that we now have a X.509 cert in the flavor of OpenSSH, which has the two principles of the IP address and the fully qualified domain name. This is an important concept in Teleport and OpenSSH; any host that you want to connect — it needs to be added to these principles. And to add them to the principles, you always need to run this tctl auth sign. Okay?

Importing Teleport CA and setting up /etc/ssh/ssh_config

Ben: So let’s look at the next steps. Okay. So the next steps we’re going to do is, on our host itself we need to update the sshd config. So we have to first do it for the user_ca that we created. So we’re going to create the user_ca. And one important when you’re copying over the ca is you need to make sure that you just ignore the cert authority and then just copy anything from the SSH RSA. Okay. So we save the Teleport cert ca. And then next up we need to do the same thing for the host key when we save these two files. Okay. So this is the private key, and we have called it open — and I’m going to do the same thing for the public. And actually, there’s something — I’ve kind of made a mistake here, but I’m going to show you how to fix it afterwards. And this is our public key. I’ve imported over the files from our auth server to our node.

Ben: Next thing we need to do is — we need to edit the sshd config. And this is the standard sshd config that you get with AWS, and you can see there’s a few different options already set here. And we’re going to come up here and add a couple of things. So we’re going to add our — first, we’re going to add our host key and a host certificate. And we also need to add our user_ca. So we have host key, host certificates, and trust the user_ca. The teleport_user_ca, we kept the same, but we did rename this file .pub. And this was just called OpenSSH. Okay. So we have saved our sshd config. Next thing we need to do is just restart SSH, and then we can just check the status.

Ben: And you can see here — let me just move this across, so that’s — I did make a mistake. So it cannot load the host key; no matching private key certificate. So what we need to do is, we just need to check that we first named and saved these files correctly. So we have the OpenSSH host, and then we have OpenSSH host hub. Okay. Yeah. You can see actually I made a typo here. It should be OpenSSH host. But I still have made another error, and I can show you how we’ll sort of reload sshd and check the status. And you can see here —unprotected private key. And actually, OpenSSH — I know in this case you may not be logging into servers to do this; you’ll probably add this as part of a provisioning process. But this is an important thing to remember; that the permissions need to be set, that are too open currently for this file. So we need to just change them and make them less open, and it will work. Change the permissions to — and you can see now everything is up and running, and it’s listening on all these ports. So we are good to go for the next step.

Accessing OpenSSH nodes using the Teleport UI

Ben: Okay. The next step is, we’re going to log in to this host. So come to my Teleport instance. I am now going to log in to Teleport. And you can see this is the same cluster that I’ve set up using Teleport configure. In this case, this is the example host that we sort of create by default. But you’ll see that the host that we have added using OpenSSH, they never get added to the server list. But you can still access them using the web UI. And to access it using the web UI, you need to do a few things. You need to know what the host was of the instance. So in our case, this is the host. And we’re going to use this box. We have to add in ec2-user at the host, and then add Port 22, and then just press return. So here we are. So we have now logged in using OpenSSH to the EC2 node that we set up. So sudo yum update, it will show you the recording. Okay. And now we’ve exited. So now I’m back under session recordings, and these are all the session recordings that happened and they’ve been recorded. And you can go back in here and play the activity. If this isn’t working for you, just make sure that in your roles you’ve been added to the auditor role. The auditor role has the ability to view and play sessions. So everything is recorded, and you can see what happened without having to install the Teleport agent on the node.

Accessing OpenSSH nodes using the terminal

Ben: Next up, I can also show you how you can use tsh to log in to that host. So we come back to the terminal, open a new window, and now I’m on my local machine. Okay. So you can see I have a range of clusters here, but I’m logged in to the bastion one. And so now I can do the same thing that I did in the web UI, to using tsh ssh. And then we pick the port, which is Port 22. And I’m ec2-user at the public domain name. And here we are. We have tsh ssh’d into Teleport. And that brings me to the end. In the next video, I’ll go over how you can use SSH agent forwarding and then also using the OpenSSH client on your machine to use the teleport_ca for accessing the hosts.

Bonus: tctl auth rotate

Ben: One other thing that I haven’t mentioned — because Teleport maintains its own CA, the Teleport agent will help you with rotation and grace periods. You have to manage all of this on your own if you’re using OpenSSH, so if you ever do a tctl auth rotate, you’ll likely want a much longer grace period for you to roll out your automation to update all of the CAs for Teleport. Thank you for watching. If you have any comments or questions, please leave a comment below.

Share this page

Try Teleport today

In the cloud, self-hosted, or open source

View Developer Docs

This site uses cookies to improve service. By using this site, you agree to our use of cookies. More info.