Skip to main content
Version: Developer

Linux authentication

When you define a static server or an AutoScaled pool, you set a Connection Credential Type, Connection Username, and Connection Password that Kasm uses to connect to the servers. The Connection Credential Type provides three values, which support the four authentication approaches described on this page. Each approach centralizes how users authenticate to Linux servers, with different trade-offs for security, concurrency, and management overhead.

Static credentials​

Select Static Credentials for the Connection Credential Type, then enter a username and password in the Connection Username and Connection Password fields of the server or AutoScale configuration. Every Kasm user connection uses these credentials to authenticate.

Advantages

  • Simple configuration.

Disadvantages

  • All Kasm users map to the same Linux user, which has security and auditing consequences.
  • The server can allow only a single concurrent session.
caution

With Static Credentials authentication, files can be stored in the Kasm Desktop Service default upload and download directories, by default /opt/kasm-desktop-service/Upload and /opt/kasm-desktop-service/Download, instead of the user's home directory. This happens when the download directory, for example ~/Downloads, does not exist or is not owned by the authenticated user. It also happens when the Connection Username is missing and the service cannot resolve a session username.

Prompt user​

Select Static Credentials for the Connection Credential Type, then leave the Connection Username and Connection Password fields blank. Kasm then prompts each user to enter a Linux username and password.

Advantages

  • Simple configuration.
  • Supports multiple concurrent user sessions per Linux server.
  • Each user can have a separate Linux account.

Disadvantages

  • Users enter their credentials every time they connect to a Linux system.
  • Features that rely on a resolved Kasm Desktop Service username, such as screenshots, storage mounts, and script- or profile-based file mappings, are not available.
caution

With Prompt User authentication over Web Native RDP, Kasm does not place uploaded and downloaded files in the user's home or profile directory, for example /home/<username>/Downloads. Instead, files are stored in the default upload and download directories configured for the Kasm Desktop Service.

Single sign-on with dynamic local accounts​

With the Kasm Desktop Service installed, Kasm manages local Linux user accounts automatically. Each time a user creates a Kasm session to a Linux server, Kasm creates a local user account if one does not already exist. Kasm assigns a random password to that account for each session.

Kasm generates the username from the first 9 characters of the Kasm Workspaces username in lowercase, with special characters replaced by a hyphen, followed by a hyphen and 10 characters from the Kasm Workspaces User ID. For example, Jon.Doe@example.com with a User ID of bf262ada-0a7f-4f49-b435-e50537caa013 produces the local Linux account jon-doe-e-bf262ada0a.

To configure dynamic local accounts, install and register the Kasm Desktop Service. In the server or AutoScale configuration, select Dynamic User Accounts for the Connection Credential Type, then enable the Kasm Desktop Service Installed option. The Kasm Desktop Service includes built-in bash scripts. One script creates local users and sets the password for an incoming session, and you can edit it for special requirements. For more details, see the Service scripts section.

Advantages

  • Supports multiple concurrent user sessions per Linux server.
  • Each user has a separate Linux account.
  • Single sign-on from Kasm to Linux, so users are not prompted for credentials when connecting.
  • Works with any Kasm authentication method, including OIDC, SAML, LDAP, and local Kasm accounts.
  • Simple configuration, with no requirement for Active Directory or other external dependencies.

Disadvantages

  • Supported only for RDP connections.

Single sign-on with Active Directory​

This option applies only when users authenticate to Kasm with Active Directory credentials and Kasm is configured for LDAP authentication. The Linux servers must be members of the same Active Directory domain that LDAP authentication uses. AutoScale configurations can join new VMs to the domain and remove them. When you use AutoScale to join VMs to Active Directory, review the Linux VM startup script README for the required configuration. The usernames that users authenticate to Kasm with must match the usernames they use to authenticate to Linux.

In the server or AutoScale configuration, select SSO User Accounts for the Connection Credential Type. Leave the SSO Domain field blank when the Kasm sign-in domain matches the Linux login domain. To change the username domain, enter a different SSO Domain. For example, when a user signs in to Kasm with jon.smith@public.domain.com but Linux login expects jon.smith@private.domain.local, set the SSO Domain to private.domain.local.

caution

After you configure LDAP-based SSO, or grant access to a workspace configured for LDAP-based SSO, users must sign out of Kasm and sign back in for SSO to work.

Advantages

  • Each user has a separate Linux account.
  • Single sign-on from Kasm to Linux, so users are not prompted for credentials when connecting.

Disadvantages

  • Additional configuration and systems add management complexity.
  • SAML and OIDC are not supported as Kasm authentication methods.