{"id":3643,"date":"2022-02-02T00:08:00","date_gmt":"2022-02-01T16:08:00","guid":{"rendered":"https:\/\/tzlee.com\/blog\/?p=3643"},"modified":"2022-02-08T16:04:37","modified_gmt":"2022-02-08T08:04:37","slug":"gravitational-teleport-as-a-bastion-host","status":"publish","type":"post","link":"https:\/\/tzlee.com\/blog\/2022\/02\/gravitational-teleport-as-a-bastion-host\/","title":{"rendered":"Gravitational Teleport as a Bastion Host"},"content":{"rendered":"\n

Gravitiational Teleport<\/a> is a pretty neat and lightweight open-source software that works great as a bastion host. However, some parts the documentation can be a bit vague for a first-time user so this blog entry serves as a reference material for myself, and hopefully it is also helpful to you.<\/p>\n\n\n\n

Introduction<\/h2>\n\n\n\n

Teleport is a great way to control access into a network of restricted systems. It can be used as a single-point-of-entry, or commonly known as a “bastion host”.<\/p>\n\n\n\n

Components<\/h2>\n\n\n\n

The same Teleport software is installed on every system, i.e. the server and the client installs the same package\/binary. The software package contains the following components:<\/p>\n\n\n\n

Service<\/th>Ports<\/th><\/tr><\/thead>
Auth<\/strong>

Authentication service to authenticate Clients and Nodes, and is also the Certificate Authority (CA) for the Teleport Cluster<\/td>		3025 (Restricted access from Nodes only)<\/td><\/tr>
Proxy<\/strong>

Web UI for public users (Clients). Tunnels SSH from Clients to Nodes. Also allows Nodes to create a reverse SSH tunnel through it for Client connections.<\/td>		443 (HTTPS, can be public to Clients, should also be reachable by Nodes)

3023 (SSH Proxy, can be public to Clients)

3024 (SSH Reverse Proxy, restricted access from Nodes only)<\/td><\/tr>
Node<\/strong>

Provides SSH access to the system.<\/td>		3022 (SSH, restricted access from Proxy only)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

A Teleport “Server” only requires two components – Proxy and Auth, although a Node usually runs on the Server as well.<\/p>\n\n\n\n

The Nodes (“Protected Resource”<\/em>) would only need to run the Node component.<\/p>\n\n\n\n

Server setup<\/h2>\n\n\n\n

In the example below, I am using an Amazon Linux 2 instance. You can refer to the installation docs<\/a> for other distros.<\/p>\n\n\n\n

Pre-requisites:<\/p>\n\n\n\n

  1. Set up an instance with a public IP address<\/li>
  2. Set up a DNS hostname that resolves to the public IP address correctly (this is required for LetsEncrypt)<\/li>
  3. Ensure the following TCP ports are open\/allowed
    1. Inbound, TCP 443, from public (required for LetsEncrypt)<\/li>
    2. Inbound, TCP 3023, from Clients<\/li>
    3. Inbound, TCP 3024, from Nodes<\/li>
    4. Inbound, TCP 3025, from Nodes (you can omit if you use reverse tunnel for Nodes behind firewall)<\/li>
    5. Outbound, TCP 3022, to Nodes<\/li><\/ol><\/li><\/ol>\n\n\n\n

      Install Teleport:<\/p>\n\n\n\n

      sudo yum-config-manager --add-repo https:\/\/rpm.releases.teleport.dev\/teleport.repo\nsudo yum install teleport<\/code><\/pre>\n\n\n\n
      Configure Teleport; replace your email and DNS hostname:<\/p>\n\n\n\n
      sudo teleport configure \\\n  --acme --acme-email=<your.email@fqdn.here> \\\n  --cluster-name=<your.dns.hostname.here> \\\n  -o file<\/code><\/pre>\n\n\n\n
      At this point, you should realise that the configuration file is \/etc\/teleport.yaml<\/code>. This file controls how and what component Teleport runs. <\/p>\n\n\n\n
      Start Teleport in foreground to test\/debug first:<\/p>\n\n\n\n
      sudo teleport start<\/code><\/pre>\n\n\n\n
      If all goes well, you should be able to reach the web interface at HTTPS port 443. Hit CTRL+C to stop, then start it as a service:<\/p>\n\n\n\n
      sudo systemctl start teleport\nsudo systemctl enable teleport<\/code><\/pre>\n\n\n\n
      User management<\/h2>\n\n\n\n
      When Teleport first starts, there are no user accounts provisioned. Add the first user:<\/p>\n\n\n\n
      sudo tctl users add --roles=access,editor --logins=root <username><\/code><\/pre>\n\n\n\n
      (This is your first interaction with the tctl<\/code> command. The tctl<\/code> command is the CLI admin tool for the Auth service. Type tctl<\/code> to see other commands available.)<\/p>\n\n\n\n
      In the example above, the user is given the access<\/code> and editor<\/code> roles to Teleport, and can login as the Linux root<\/code> user to Nodes.<\/p>\n\n\n\n
      To see what roles are available:<\/p>\n\n\n\n
      sudo tctl get roles<\/code><\/pre>\n\n\n\n
      Once the user is added, a sign up URL is provided. Send it to the user to set up his\/her Teleport account, including registering an OTP. OTP is mandatory.<\/p>\n\n\n\n
      Note that Teleport does not create the logins on the Nodes. If the login does not exist, an attempt by the user to access the Node will simply fail.<\/p>\n\n\n\n
      Node setup<\/h2>\n\n\n\n
      In the example below, I am using an Ubuntu instance. You can refer to the installation docs<\/a> for other distros.<\/p>\n\n\n\n
      Pre-requisites:<\/p>\n\n\n\n