View Source

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.

Versions 8.3.5 and newer of the tsh application support use of proxies (HTTP_PROXY , etc). However, if the HTTPS_PROXY , etc, environment variable is set, tsh will also attempt to make an ssh connection on port 22 using the proxy. If your proxy does not support ssh connections to port 22 then set:

$ export no_proxy="jump.ecmwf.int:22"

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 TOTP security token
- upon successful authentication, tsh receives a callback from jump.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 the standard port 22 for server access.
The Teleport web shell service uses port 443 on the same host.