Remoteler automates Certificate Authority (CA) management and issues short-lived and scoped certificates for SSH, RDP, Kubernetes, and database authentication.
Remoteler comes with its own
ssh client –
tsh. When a user types
ssh host command, Remoteler will check if a user has a valid SSH certificate in the
~/.tsh directory or loaded into an
ssh-agent. If no certificate is found, it will trigger the login sequence.
A user can force the login sequence by executing:
$ tsh login --proxy=customer.remoteler.com
This command takes the Remoteler Proxy Service’s address as an argument.
The diagram below illustrates the login sequence. Remoteler authentication uses SAML 2.0/OIDC Connect/OAuth2 family of protocols, depending on the identity store. In this example the identity store is Github:
Upon successful authentication, an SSH certificate will be stored in the user’s ~/.tsh/keys directory and loaded into an ssh-agent, if there is one running. If Kubernetes support is enabled, an x509 certificate for Kubernetes will be stored there as well, and ~/.kube/config will be updated with it.
The Remoteler client stores the Remoteler Proxy Service URL in ~/.tsh/profile. The user does not need to use the –proxy flag again. They can edit the profile file when connecting to multiple Remoteler clusters.
SAML, OAuth2, and web browsers are great for interactive authentication for humans.
If authentication is needed for legacy automation similar to Jenkins, which relies on SSH credentials, a Remoteler administrator can issue a certificate via:
$ tctl auth sign -o jenkins.cert
It is recommended that such certificates be stored in secure storage.
When a user is authenticated, they can establish SSH and Kubernetes connections to a cluster:
# using SSH $ tsh ssh hostname # using K8s $ kubectl get pods
The Remoteler client is called
tsh, but you can rename it
ssh, and this enables full command-line compatibility with OpenSSH client.
The diagram below shows how a connection is established:
~/.tsh/profilefile and relays to it the hostname of the destination hostname.
* By default, connections are encrypted end to end, but Remoteler also supports the recording proxy legacy mode if the audit is required for legacy
sshd daemons. In this mode, the proxy decrypts the connection and sends the audit information to the Remoteler Auth Service.
Unlike traditional OpenSSH-based workflows, Remoteler allows users to log out. “Logging out” means erasing previously obtained certificates from a client machine.
$ tsh logout