...
| Note |
|---|
Since 2016 the ecAccess ssh module has required custom configuration on the ssh client end to enable known-insecure ciphers. |
...
ecauth receives the TCP/IP connection from ecAccess and spawns a shell as the original user (sy0, in this example).
| Note |
|---|
It is important to know that the user authenticates to the ecAccess gateway only, not the destination server or workstation. |
Understanding our SSH Proxy service
...
| Info |
|---|
The need for the SSH Proxy is mostly to support a network setup where the Centre is dual-homed on both RMDCN and Internet. |
...
This is a commonly used behaviour in ssh, and in fact new openssh clients and servers support the ProxyJump setting, to simplify configuration even further.
| Note |
|---|
It is important to know that our SSH Proxy is not authenticating users; it merely passes a TCP/IP stream. |
Understanding Teleport
Teleport functions somewhat like a combination of ecAccess, and the SSH Proxy service, with additional features relating to role-based access control and single sign-on.
Clients outside of the Centre configure their clients to use Teleport as a proxy service for the destination host or server. That is, it's a bit like the reverse of systems inside ECMWF connecting to the Internet.
...
The notable difference between Teleport and our current services is that a specific command-line application, called tsh, is required to do the single sign-on function (once per day).
| Info |
|---|
With Teleport, users are authenticated both at the gateway and at the destination host. |