Network Requirements

The Teleport service is configured to use only standard ports 22, 80, and 443, to help with access wherever users are.

Additional configuration at the local user site may be required to allow outgoing connections. The diagram below shows the TCP ports and destination hosts used.

Currently the tsh application does not support use of proxies (HTTP_PROXY , etc). The developers are actively working on a fix for this which will be available in a forthcoming release.
Workaround options are to use a TCP proxy wrapper app, such as proxychains-ng, or to make use of the Web Shell facility.

The "tsh login" step uses ports 80 and 443 in order to log in to the service and obtain the client certificate.
- initially it contacts jump.ecmwf.int on port 443 (the user is able to see these steps by using the "tsh login --debug" option)
- then it opens a local http client on a high port 64xxx, produces a URL link on the localhost for the user to follow (such as: http://127.0.0.1:64068/da92794b-9d41-4008-ae6f-83fb77f64486) and waits for a callback from jump.ecmwf.int.
- that localhost URL then redirects the user for OIDC authentication at https://accounts.ecmwf.int (on port 443) involving Keycloak linked to user accounts on ActiveDirectory and the ActivIdentity (HID) security token
- upon successful authentication, tsh receives a callback from shell.ecmwf.int and receives the client certificate completing its login workflow
- from this point on, with the client certificate which is valid for 24 hours, the user is authorised to access hosts behind the teleport proxy either via tsh ssh or OpenSSH workflows
Your ssh client uses standard port 22 for server access.
The Teleport web shell service uses port 443 on the same host.

The diagram describes the set up for the Teleport instance installed at ECMWF's Data Centre in Bologna. An instance installed in the Reading Data Centre uses the same ports but different hosts and will be decommissioned at the end of 2022.