Table of Contents
- Installing Teleport 7.X CE server under Centos7
- (ALTERNATIVE) Installing Teleport 8.X (current latest) CE server under Centos 7
- Initial configuration and domain setup
- Start Teleport and make sure it is working
- Creating Your First Teleport User
- Adding SSH Nodes To The Cluster
- Using Teleport (TSH) To Connect To SSH Nodes
- Some Bonus Tips
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:
(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 )
- firstname.lastname@example.org –> an email address you have access to
Let’s edit the default teleport configuration file:
# 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: email@example.com
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:
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:
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
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:
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.
- On your laptop or working machine, download the Teleport .tar.gz file, for example: teleport-v7.3.8-linux-amd64-centos6-bin.tar.gz
- Untar the archive:
tar -xvzf teleport-v7.3.8-linux-amd64-centos6-bin.tar.gz
- Go to the directory:
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 firstname.lastname@example.org
Some Bonus 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:
Resetting Teleport State
You can reset teleport state by removing
/var/lib/teleport directory and re-starting teleport.