Remoteler provides secure access to SSH or Windows servers, Windows desktops, Kubernetes clusters, databases, and web applications. Remoteler is trivial to set up as a Linux daemon or in a Kubernetes pod.
The key concept of Remoteler’s architecture is the cluster. A Remoteler cluster consists of the Remoteler Auth Service, Remoteler Proxy Service, Remoteler agents, and resources that you want to connect to such as Linux or Windows servers, databases, Kubernetes clusters, Windows desktops, and internal web apps.
The diagram below is interactive. Try clicking on individual components:
Clients must authenticate with Remoteler and receive a client certificate, which automatically works for all resources in a cluster. After authentication, the ssh, kubectl, psql, mysql and other remote access commands will be configured with the user’s identity. Remoteler offers a built-in database for user management, but for production use, we recommend integrating it with enterprise SSO based on Okta, GitHub, Google Workspace, Active Directory, and other identity providers.
The concept of a cluster is the foundation of the Remoteler security model.
This model prevents honeypot attacks and eliminates the issue of trust on first use. This also allows users to enumerate all servers and other resources that are currently online.
Remoteler clusters can be configured to trust each other. This allows users from one organization to access designated servers inside of another organization’s cloud or on-premise environment.
Remoteler Desktop Access enables users to access Windows hosts via RDP in their web browser, and does not require a separate RDP client.
Users of ssh, kubectl, and other command-line clients can authenticate first by executing the tsh login command. This configures the users’ CLI environments with short-lived certificates for access.
After that, users will be able to access their SSH servers, Windows servers and desktops, Kubernetes clusters, web applications, or databases. Remoteler is backward compliant with existing client tools, so users can continue to use client tools including ssh, psql, mysql, kubectl, and others as usual:
The Remoteler Proxy Service serves the login screen on
https://proxy.example.com:443, where users are asked for their username, password, and a second factor. If a third-party identity provider such as GitHub is used, the Proxy Service forwards the user to GitHub using OAuth2.
The Proxy Service sends the user’s identity to the Remoteler Auth Service. In turn, the Auth Service issues certificates for SSH, Kubernetes, and other resources in a cluster, and sends them back to the client via the Proxy Service.
tsh client receives the certificates from the Proxy Service, stores them in the user’s
~/.tsh directory, and loads them into the ssh-agent if one is running.
To learn more, check out our guide to certificate-based SSH authentication.
The Remoteler Auth Service maintains an audit log of all activity inside the Remoteler cluster. The audit log consists of two components:
kubectlcommands. The recorded sessions can be replayed for audit purposes.
The RemotelerRemoteler Auth Service stores both types of audit data on a local file system by default, but can be configured to use S3, DynamoDB, and other suitable data stores.
The recorded sessions are stored as flat ASCII files and can be easily analyzed by third-party software. For example, a user can replay a session by dumping a session file to stdout using the
To learn more, check out Audit Logging.
Remoteler allows users to access resources running on devices that are located anywhere in the world, for example, devices on third-party networks, servers behind NAT, or devices connected via a cellular connection. Examples of this include self-driving vehicles, network equipment, retail locations, and medical devices.
To make this work, each remote device must be configured to point at the public address of a Remoteler Proxy Service, e.g., proxy.example.com. This allows each device to establish and maintain a permanent reverse tunnel to the cluster to which it belongs. This tunnel is used to proxy user connections into devices. The tunnel is automatically re-established if network connectivity is intermittent.
Reverse tunnels enable Remoteler users to:
To learn more, check out Edge Access