info@remoteler.com 561.316.7343
How Remoteler Works

Certificate-Based Authentication

Remoteler automates Certificate Authority (CA) management and issues short-lived and scoped certificates for SSH, RDP, Kubernetes, and database authentication.

The basics

Certificate-based authentication is the most secure form of authentication, but historically, it has been the most complicated to manage. You have to run a Certificate Authority (CA) and distribute server and client certificates which impedes its adoption at scale. One of our design goals for Remoteler has been to securely automate CA and certificate issuance, making certificate-based authentication easy.

Remoteler supports all the necessary certificate management operations to enable certificate-based authentication. Remoteler operates two internal Certificate Authorities (CA) as a function of the Remoteler Auth Service. One is used to sign User certificates, and the other signs Node certificates. Each certificate is used to prove identity, cluster membership, and manage access.

By default, all user certificates have an expiration date, also known as the time to live (TTL). This TTL can be configured by a Remoteler administrator. However, the node certificates issued by the Remoteler Auth Service are valid indefinitely by default. Remoteler supports certificate rotation, i.e. the process of invalidating all previously-issued certificates for nodes and users regardless of their TTL.

Authentication Flow for SSH

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:

  1. The client requests a certificate via tsh login. This command launches a web browser on a client’s machine and directs it to a Remoteler Proxy Service.
  2. The Remoteler Proxy Service redirects the user to Github’s login page, using Github’s 2FA.
  3. Upon successful Github authentication, the browser is redirected back to the proxy, which forwards user identity to the Remoteler Auth Service.
  4. The Remoteler Auth Service issues a certificate with a configured time to live (TTL) and it is returned to the client.

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.

Authentication for Services

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.

Connecting to Nodes

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:

  • The client dials to the Remoteler Proxy Service specified in ~/.tsh/profile file and relays to it the hostname of the destination hostname.
  • Remoteler Proxy Service does not perform any decryption or authentication*, it simply performs a name resolution for the given hostname and tries to relay the SSH connection to it. The user connection is shown in green.
  • The destination host validates the user’s certificate and begins logging user actions to the Remoteler Auth Service using its audit connection. The connection between a host and the Remoteler Auth Service is also authenticated via the host’s certificate and encrypted. The audit connection is shown in red.
  • If the destination host is a remote host, such as an IoT node (self-driving vehicle or a smart device) the connection is established using the reverse tunnel that remote nodes always maintain.

* 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.

Logging Out

Unlike traditional OpenSSH-based workflows, Remoteler allows users to log out. “Logging out” means erasing previously obtained certificates from a client machine.

$ tsh logout

Try Remoteler Today!