Teleport is software which provides an SSH Jump Host (or Bastion host) service in a secure, modern, way, with support for role-based access control, and single sign-on.

It is a replacement for the ecAccess SSH service, and is operated by the CD Apps team and User Support.

This service is under development and not widely accessible. Please continue to use the existing ECAccess service!

Downloading `tsh`

The tsh application is required to perform user authentication once every eight hours.

tsh is open source, very portable, and has minimal dependencies.

Download from the Gravitational website and place into your $PATH

The binary is available for Linux 32-bit, 64-bit, and ARM, as well as signed packages for MacOS and Windows 64-bit.

User Authentication

Once every eight hours, you will need to refresh your tokens by logging in to the ECMWF website.

First Time

Run tsh, giving the location of our gateway:

tsh login --proxy=shell.ecmwf.int:443

Your default web browser will open and you should login with your email address, workstation password, and then HID Token code.

Subsequent Occasions

tsh login

If you're already logged in to the ECMWF website, or have recently logged in to this service, the password prompt might be skipped.

Connecting to hosts through the gateway

OpenSSH 7.3 or newer has a simple command line option, to connect via our gateway shell.ecmwf.int to the destination-host:

ssh -J username@shell.ecmwf.int username@destination-host

For example, if your username is ab0 and you wish to connect to ecgate:

ssh -J ab0@shell.ecmwf.int ab0@ecgate

The OpenSSH configuration setting for this is named ProxyJump:

Legacy Configuration

For OpenSSH clients older than 7.3, the following will work in your ~/.ssh/config file:

Host ecgate
  Username ab0
  ProxyCommand /usr/bin/ssh -q -W %h:%p shell.ecmwf.int

Configuring servers and workstations for Teleport

At the destination host end, openssh needs to be configured to trust the SSH Certificate that your client is passing.

This can be done at the server level for all users, or by an individual user within their own account.

If a user configures this for their own account, it will potentially allow access to any other system using the same $HOME filesystem.

A user can add the following to their ~/.ssh/authorized_keys file:

cert-authority ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDN85frMTtRzQaVjkHGM3NTOJD/5awWn2i1sAofzlO0PXM1jX/H+4zQKn1+ATUqU+TTU2v3V7fhZm0cWqRrofSLDVC80FkCFqzZRq2E4kMBP5sx4yf/mBKLzJ6luE8eV/3W0V6KEch5TV2ON8ltwFPWjB3D/puPU010UOJH/arlpW5h+n9dAtBCAtVuMYBEz/5uWcKcTJkFe2usQTVmpiEmt/yAx4LfLTFPs2+izLo+N3dBW92HFnKnQftZI5s8ysOENbKmxdWfcxdID5E91oneAvkmEKBeUutlYY3GV9621iuKnlEw6WF8wfQapdozzhSyb+LhqPDiBRotnerhA69/ clustername=tele&type=user

A server administrator can place the same key into /etc/ssh/teleport-user-ca.pub

They would then add the following to their /etc/ssh/sshd_config file:

AuthorizedKeysFile /etc/ssh/teleport-user-ca.pub .ssh/authorized_keys .ssh/authorized_keys2

Having a dedicated file for the trusted key means that it can easily be rotated using configuration automation.

SCP, X11 and Port Forwarding

scp, X11, and port forwarding will all work through the Teleport gateway.

Of course, such features also need to be permitted on the destination server or workstation.

See the AUTHORIZED_KEYS section of the sshd man page for how to configure restrictions on users coming via Teleport.

Downloading tsh