Install And Configure Teleport On Centos 7 / RHEL 7

Gravitational Teleport is a nice tool for centralizing and securing accesses to hosts and services on your infrastructure. 

In the following how-to I’ll explain how to: 

• Install Teleport Community Edition server under Centos 7 
• Install Teleport CE client under Centos 7 
• Configure your first access user 
• Configure an access limited user 
• Some hints for better securing your setup 

 

Installing Teleport 7.X CE  server under Centos7 

First let’s add the teleport repo and make it ‘enabled=0‘ by default.

 

yum-config-manager --add-repo https://rpm.releases.teleport.dev/teleport.repo


vim /etc/yum.repos.d/teleport.repo 
#....
enabled=0
#....

 

The reason, we need to make the repo disabled by default, is because the current newest version of teleport (as of this writing) is Teleport 8.x and it is not compatible with the older glibc used by Centos/Rhel 6.x/7.x.

If  you accidentally update teleport to 8.x , you will most probable end up with failing to start app, throwing the following error: 

teleport: /lib/libc.so.6: version 'GLIBC_2.28' not found (required by teleport)

 

Now let’s check which is the newest version 7.x available: 

yum --enablerepo teleport --showduplicates list teleport
yum --enablerepo teleport install teleport-7.3.8-1

Currently the highest version is: teleport-7.3.8-1

 

(ALTERNATIVE) Installing Teleport 8.X (current latest) CE server under Centos 7

 

 

yum install libatomic
yum-config-manager --add-repo https://rpm.releases.teleport.dev/teleport.repo
yum install teleport

 

Initial configuration and domain setup

In order to make the initial configuration you will need:

• email address to use in the acme config section
• domain pointed to the IP of your teleport server

 

In this example I will assume your domain/email addresses are: 

• teleport.example.org –> pointed to 192.168.1.1 (if we assume 192.168.1.1 is your server’s ip ) 
• user@example.org –> an email address you have access to 

 

Let’s edit the default teleport configuration file:

vim /etc/teleport.yaml

# More info on configuration options could be found here: 
# https://goteleport.com/docs/setup/reference/config/


teleport:
  nodename: teleport.example.org
  data_dir: /var/lib/teleport

  log:
    output: /var/lib/teleport/teleport.log
    severity: INFO
    format:
      output: text

  ca_pin: []
  diag_addr: ""

auth_service:
  enabled: "yes"

  # ProxyProtocol enables support for HAProxy proxy protocol version 1 when it is turned 'on'.
  # Verify whether the service is in front of a trusted load balancer.
  # The default value is 'on'.
  proxy_protocol: on

  listen_addr: 0.0.0.0:3025

  cluster_name: teleport.example.org

  # Optional setting for configuring session recording. Possible values are:
  #    "node"  : sessions will be recorded on the node level  (the default)
  #    "proxy" : recording on the proxy level, see "Recording Proxy Mode"
  #              (https://goteleport.com/docs/architecture/proxy/#recording-proxy-mode).
  #    "off"   : session recording is turned off
  #
  # EXPERIMENTAL *-sync modes
  # Proxy and node send logs directly to S3 or other storage without
  # storing the records on disk at all. *-sync requires all nodes to be
  # upgraded to 4.4.
  #
  #    "node-sync" : session recordings will be streamed from node -> auth -> storage service
  #    "proxy-sync : session recordings will be streamed from proxy -> auth -> storage service
  #
  session_recording: node 

  # Determines if SSH sessions to cluster nodes are forcefully terminated
  # after no activity from a client (idle client).
  # Examples: "30m", "1h" or "1h30m"
  client_idle_timeout: never

  # Send a custom message to the client when they are disconnected due to
  # inactivity. The empty string indicates that no message will be sent.
  # (Currently only supported for SSH connections)
  client_idle_timeout_message: ""

  # Determines if the clients will be forcefully disconnected when their
  # certificates expire in the middle of an active SSH session. (default is 'no')
  disconnect_expired_cert: no




# -------
# This applies for end-nodes only 
# -------------------
ssh_service:
  enabled: "yes"
  labels:
    env: teleport_server
  commands:
  - name: hostname
    command: [hostname]
    period: 1m0s


proxy_service:
  enabled: "yes"
  listen_addr: 0.0.0.0:3023
  web_listen_addr: 0.0.0.0:443
  public_addr: teleport.example.org:443
#  https_keypairs: 
#     - key_file: /var/lib/teleport/sh_wild.key
#       cert_file: /var/lib/teleport/sh_wild.crt
  acme:
    enabled: "yes"
    email: user@example.org

 

You should also make sure you have the following teleport ports open for external connections: 

3022, 3023, 3024, 3025, and 443

 

In the config above we are using the ‘acme’ setup, which will use Let’s Encrypt to automatically issue a certificate for the domain of your cluster name ; teleport.example.org . If your domain does not point to your server, Let’s encrypt would fail to validate your domain ownership and issue certificate, so you won’t be able to start teleport. 

If you want to provide your own certificates for the web access, you could change acme.enabled to ‘no’ and uncomment the ‘https_keypairs’ section, by putting paths to your own SSL cert and key. 

 

Start Teleport and make sure it is working

First we need to enable/start the service by systemd: 

systemctl enable teleport 

systemctl start teleport 

 

Then we should validate if it is working, by accessing in the browser: 

https://teleport.example.org

If everything is okay, you should see something like this: 

 

Creating Your First Teleport User

Now it is time to create our first teleport user, which is made inside the teleport server. 

 

[root@teleport ~]# tctl users add teleport-admin --roles=admin,editor,access --logins=root        
User "teleport-admin" has been created but requires a password. Share this URL with the user to complete user setup, link is valid for 1h:

https://teleport.example.org:443/web/invite/de4a8018c48deb0efa52d42860123123s

NOTE: Make sure teleport.example.org:443 points at a Teleport proxy which users can access.

This will create a super user with most of the possible privileges. 

And then, we must go to the provided URL and setup password + 2FA authenticator. 

The 2FA barcode, must be scanned with some Authenticator App – Google Authenticator or 1Password or Whatever…and then you should be able toe get the two-factor Token generated by the app. 

After creating your user, you will be able to login inside https://teleport.example.org admin panel and see at least one node configured (your teleport server itself) and also be able to login inside the server by using web console. 

 

Adding SSH Nodes To  The Cluster

The main function of Teleport is to enable users to securely connect to a different nodes (ssh nodes). 

In order this to happen, the following steps must be done:

• Generate node join token on Teleport Server 
• Install Teleport on Client Node and add configuration file with the previously generated join tokens 

 

First – Generate joining token for the new node.

[root@teleport ~]# tctl nodes add --ttl=150m --roles=node 
The invite token: 7b708929fd50ef2794281b231230176.
This token will expire in 150 minutes.

Run this on the new node to join the cluster:

> teleport start \
   --roles=node \
   --token=7b708929fd50ef2794281b231230176 \
   --ca-pin=sha256:7b708929fd50ef2794281b2312301767b708929fd50ef2794281b231230176 \
   --auth-server=192.168.1.1:3025

 

Second – Install Teleport on client node and start it 

Now on the client node server, we must install teleport (we can use the same yum steps as above). 

But before enabling/starting the service, let’s put a client config: 

vim /etc/teleport.yaml

teleport:
  auth_token: 7b708929fd50ef2794281b231230176 
  ca_pin: sha256:7b708929fd50ef2794281b2312301767b708929fd50ef2794281b231230176 
  auth_servers: 
   - "192.168.1.1:3025"

ssh_service:
  enabled: yes

  commands:
  - name: hostname
    command: [hostname]
    period: 60m0s

  listen_addr: 192.168.1.2:3022

        
auth_service:
  enabled: no
proxy_service:
  enabled: no
app_service:
  enabled: no
kubernetes_service:
  enabled: no
db_service:
  enabled: no

Let’s explain some of the settings here: 

These are the token/ca_pin, generated from the Teleport Server

auth_token: 7b708929fd50ef2794281b231230176

ca_pin: sha256:7b708929fd50ef2794281b2312301767b708929fd50ef2794281b231230176

 

This is the IP of the Teleport Server

auth_servers: – “192.168.1.1:3025”

This is the IP address of the SSH Client Node: 

listen_addr: 192.168.1.2:3022

FInally we can start Teleport on our client node. 

systemctl enable teleport 

systemctl start teleport

 

!!! Make sure port ‘3022’ is accessible from the teleport server !!!

 

Using Teleport (TSH) To Connect To SSH Nodes 

By now you should be able to SSH inside your 2 added nodes (teleport server and teleport client node)  by using the Web Interface. 

Here is how to do this by using the CLI tools provided. 

 

1. On your laptop or working machine, download the Teleport .tar.gz file, for example: teleport-v7.3.8-linux-amd64-centos6-bin.tar.gz
2. Untar the archive:  tar -xvzf teleport-v7.3.8-linux-amd64-centos6-bin.tar.gz
3. Go to the directory: cd teleport

 

Now you can execute the necessary tsh command to authenticate in the server: 

# Change teleport.example.org  with your actual domain name 
# Enter your password + the 2FA token 
./tsh login --proxy=teleport.example.org:443 --auth=local --user=teleport-admin

 

Now you should be able to connect both of the added nodes: 

# List the currently added nodes 
./tsh ls 

# Connect to a specific node 
./tsh ssh root@example-node.example.org

 

Some Bonus Tips 

Security Tips

Here are some advices regarding my short usage of Teleport: 

• Make sure the communication between nodes and server is done through internal interfaces preferably 
• On client nodes, make sure 3022 port is accessible only from the Teleport server (you should limit the access by some sort of FW , iptables for example) 
• Preferably make the server accessible only from internal networks 
• Whoever has access to the teleport server would be able to create/modify admin users inside database 

 

Some info about logging 

With the setup we’ve just made, you can find session recordings and audit logs in the following directory: 

`/var/lib/teleport/log/records`

 

Resetting Teleport State 

You can reset teleport state by removing /var/lib/teleport directory and re-starting teleport.