Luminate platform provides secure access to various types of applications and services. This article describes the principles of using Luminate to access Linux (and other) servers using SSH Protocol without exposing the servers to external networks.

If you need some background on the basic principles of the Luminate platform, please refer to the Getting Started Article, that explains the solutions in general, and provides step-by-step instructions to providing access to Web Servers / Applications.

Providing SSH access is similar (from the communications flow perspective) to the basic scenario of Web Servers / Applications, but introduces a number of additional features as a result of capabilities of the SSH Protocol.

The SSH Access functionality of Luminate can support the following scenarios:

  1. Access to Secure Shell of Unix/Linux servers (or any other servers supporting SSH)
  2. Access to SSH Protocol Extensions, such as SCP and SFTP (for copying files over a secure connection)
  3. Access to dedicated applications that use SSH as a Transport Layer (for example, Git source versioning system)
  4. TCP-layer access to any server from any application using SSH Tunneling

In order to explain how the access to SSH Servers works with Luminate, we need to explain the components and steps involved in the communication:


  1. The user connects to the Luminate User Portal, undergoing all the necessary authentication steps (including Multi-Factor authentication, Host/Device posture check, etc...)
    • The user chooses which SSH Server he / she would like to access and receives either a temporary access token or a special RSA key
  2. The user initiates an SSH connection from his / her device, using the access token or the RSA key for authentication
  3. Luminate Connector, deployed in the network allowing connectivity to the SSH Servers opens a connection to the Luminate cloud, waiting for requests to connect users to the servers
  4. Upon successful authentication of a connection in step #2, the user is connected to the SSH Server

The connection created in step #4 is using a short-lived certificate, dynamically allocated by the Luminate system, to connect to the SSH Server. In order to be able to support such connections, a one-time operation of installing a Public Key of the Luminate Certificate Authority (unique for each Luminate tenant) needs to be performed on the SSH Server machine.

The procedure (for Linux Servers) is described in the following article:

Following steps need to be performed in order to allow SSH Access to a server:

  1. Deploy a Luminate Connector in a network with direct IP connectivity to the server (if there is still no such connector). The Connector can allow SSH Access to the same host it is running on, or to any other host in the network. The procedure is described in the following article:
  2. Deploy a Public Key of the Luminate Certificate Authority on the SSH server, as described in the following article:
    • Alternatively, please refer to this guide for authenticating to the internal servers interactively, instead of using PKI
  3. Create an SSH Application in the Administration Portal, as described in the following article: 

The user experience for accessing an SSH server via Luminate consists of the following steps:

  • Log-in to the Luminate user portal and choose the SSH server to connect to (this step and the next one are not mandatory if the user knows the name/address of the SSH server)



  • Click on the icon representing the SSH server in the Luminate user portal to get the connection information and choose the authentication method. 

There are two supported SSH authentication methods: Temporary Access Token and RSA Key. 

Using Temporary Access Tokens

When using this authentication method, a random access token is being generated by a UI (can be copied to clipboard) that should be provided to an SSH client at the login stage.

In addition to the access token, the UI below contains both connection settings to be used in any SSH or SSH-enabled client, along with a full command-line for an OpenSSH client, to initiate the connection.


Upon initiating an SSH connection with access token, the user will be prompted to provide it as an authentication factor. Below screenshot is showing its usage with an Putty SSH application (on Windows):


Please note that the authentication performed using the access token is done with the Luminate SSH service. The authentication with the actual SSH server will be performed using a dynamically-generated (by Luminate) certificate, signed by the Certificate Authority represented by a public key deployed on the server.

Using RSA Keys

When using this authentication method, Luminate generates a special RSA Key for the user. This key can only be accepted by the Luminate platform and serves as an identity toen for that user. Access to any SSH servers will be subject to the access permissions assigned to the user (and/or groups he/she is a member of) in the Luminate Administration Portal.

The user first Generates a Key Pair using the Luminate Portal:


Upon generating the key pair the user will be presented with the following window, allowing to download the private key (and to copy the public key):


Important Note: the downloaded private key, until expired or revoked, contains the user identity and can be used for accessing organizational resources that the user is entitled to access. It should be kept very securely, preferably in the special protected keys storage on the device.

Please Note that, for security reasons, the Luminate platform is not storing the private key anywhere, therefore, if the downloaded private key file was lost, there is no way to recover it, and the user will need to generate a new key.

After generating the key pair, the users can connect to SSH Servers via Luminate using the downloaded private key as the means of identity for authentication.

  • Auditing of the performed operations

All operations performed throughout the session can be recorded for auditing purposes. Sensitive operations can cause automatic orchestrated responses.

The below screenshot shows a sample audit trail for an SSH session: