Servers

Kasm Workspaces provides session management and rendering of sessions for fixed systems or auto scaled systems that support either KasmVNC, RDP, SSH, or VNC. Workspaces can be created and assigned to Groups, providing users access to the servers from their dashboard.

Create Server

To create a new server, navigate to Infrastructure->Servers and click Add. Fill in the required information about the server. In order for the server to be accessible to users, a Workspace must be created and then add the Workspace to a Group.

Property	Description
Enabled	Show and allow connections to this server.
Friendly Name	The server name displayed to users.
IP/Hostname	The IP or Hostname used to connect to the server.
Connection Type	Whether to use KasmVNC, RDP, SSH, or VNC.
Connection Port	Which port to connect to the server on.
Connection Credential Type	Which type of credentials are used for this server. Options are Static Credentials, Dynamic User Accounts, SSO User Accounts, and Authenticate with Smartcard
SSO Domain	This field applies when Connection Credential Type is set to SSO User Accounts. Use this field to modify the username. For example, in Kasm the username may be john.smith@acme.com, but Windows may expect john.smith@acme.local. A value of localhost strips the domain name from the username, i.e. john.smith. A value ending in \ prepends this field to the username, i.e. acme.local\john.smith. All other values are appended to the username with @, i.e. john.smith@acme.local.
Connection Username	The username to use to connect to the server. Only visible with Static Credentials Connection Credential Type.
Connection Password	The password to use to connect to the server. Only visible with Static Credentials Connection Credential Type.
Use User SSH Key	(Optional) This only applies to the SSH Connection type. When selected Kasm uses the User’s SSH Keys to authenticate against the server.
Connection Private Key	(Optional) This only applies to the SSH Connection type. This is the private key to be used to authenticate to the server.
Connection Private Key Passphrase	(Optional) This only applies to the SSH Connection type. This is the passphrase of the Private Key specified above.
Connection Info	(Optional) Additional connection info that needs to be passed to the server. For more information see the Connections section of the global settings
Max Simultaneous Sessions	The maximum amount of sessions that can connect to the server at a time. For RDP servers with RemoteApps, admins may want to set this value higher than then Max Simultaneous Users setting to allow for multiple RemoteApps per user.
Max Simultaneous Users	For RDP and SSH servers, the number of concurrently connected users per server.
Deployment Zone	Which deployment zone to set for the server.
Pool	Which pool does the server belong to.

Single Sign-On to Windows Systems via LDAP

When users login to Kasm via LDAP Authentication, they are able to create sessions to Windows systems that are joined to the same Active Directory domain and are configured for SSO credential pass-through. In the above table covering the configuration fields for Servers is the Connection Credential Type field. Select the value SSO User Accounts in the Connection Credential Type field. This requires that all users accessing this server are authenticated to Kasm using LDAP authentication. See our Windows Deployment Guide video for a walk through of this topic and more.

Authentication Options When Connecting to an SSH Server

Kasm Workspaces has the ability to connect to arbitrary SSH servers. It can use SSH key or password authentication. There are a few combinations of options on the Server edit screen that can be selected.

The server can be configured to use:

Username/password authentication
Username and select the Use User SSH Key to send the username and private key stored with the Kasm user.
Username and a pasted in private key, optionally including a passphrase if the key requires one.

Select the value SSO User Accounts in the Connection Credential Type field and check the Use User SSH Key checkbox and Kasm Workspaces will send the user’s Kasm Workspaces username along with the user’s Kasm Workspaces SSH key allowing easy multiple user support on SSH servers.

There are some restrictions on the ssh keys supported that are enforced by the connection proxy library used for the ssh server connections: The SSH key must be an ssh-rsa key in PKCS1 format (i.e. the header of the key starts with -----BEGIN RSA PRIVATE KEY-----) with a key size of 2048. In addition, some newer Linux distributions such as Ubuntu 22.04 LTS will not accept ssh-rsa keys by default. To work around this edit the /etc/ssh/sshd_config file on the target server and add these two lines to the config.

HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedKeyTypes +ssh-rsa

SSH session continuity

Kasm Workspaces uses Guacamole to provide SSH connectivity for SSH server definitions. Guacamole does not provide the ability to resume SSH sessions. This means that when disconnecting from an SSH Workspace such as when clicking Workspaces from the control panel it will not be possible to resume the same session when clicking Resume and a fresh SSH session will be created. This also applies to disconnections caused by network interruptions. To avoid this a user can utilize a utility such as screen/tmux to have a persistent terminal session on the server.

Tmux Connection Settings Example

This is an example of how it would be possible to configure the Kasm connection settings for a Server to use tmux to have a preserved environment on an SSH server.

{
  "guac": {
    "type": "ssh",
    "settings": {
      "font-size": "11",
      "color-scheme": "gray-black",
      "font-name": "monospace",
      "scrollback": "1000",
      "command": "tmux a || tmux"
    }
  }
}

Screen Connection Settings Example

This is an example of how it would be possible to configure the Kasm connection settings for a Server to use screen to have a preserved environment on an SSH server.

{
  "guac": {
    "type": "ssh",
    "settings": {
      "command": "screen -R my_session"
    }
  }
}

Creating Templates For Use With The VMware vSphere Provider

When using the VMware vSphere provider the administrator must create templates on the cluster for the provider to clone from.

Linux Templates

When creating Linux VM templates ensure that:

VMware tools, either the official version or the open-vm-tools are installed.
If SSH access is desired ensure that a public SSH certificate is installed on the machine, and use the matching private key when creating the Autoscale documentation.
If creating this template for use in a Docker Agent pool take note of the primary ethernet interface name as that will be needed for the autoscale startup scripts.

Troubleshooting Linux Startup Script Execution

The startup script will be copied to a temporary directory on the Linux host, this is usually /tmp. inside the temporary directory VMware will create a folder named vmware-root_ followed by a set of random numbers e.g. vmware-root_437-1849036237. Then VMware will create the script file inside this directory also randomly named e.g. vmware119.sh. VMware does not provide a logging facility for executing these scripts but the script writer could log important events by creating an adjacent file and writing to it. If the script fails during testing of the Autoscale/vm-provider configuration the administrator can bring up VMware console access to the cloned machine, find the script in the temporary directory and manually execute the script to observe it’s output.

Windows Templates

When creating a Windows VM template ensure that:

VMware tools is installed.
Remote desktop has been enabled on the VM.
The startup script entered into the VM Config Provider will be run as a Powershell script, so ensure that unrestricted remote scripting is enabled.
If desired ensure that the Kasm Desktop Service is installed, this will make uploads and downloads available from the Kasm Control Panel.

Troubleshooting Windows Startup Script Execution

The startup script will be copied to a temporary directory on the Windows host, this is usually the directory pointed to by %TEMP%. This environment variable must be resolved when logged in as the user the script will be executed as to give an accurate location. Inside the temporary directory VMware will create a folder named vmware-root_ followed by a set of random numbers e.g. vmware-root_437-1849036237. Then VMware will create the script file inside this directory also randomly named e.g. vmware119.sh. VMware does not provide a logging facility for executing these scripts but the script writer could log important events by creating an adjacent file and writing to it. If the script fails during testing of the Autoscale/vm-provider configuration the administrator can bring up VMware console access to the cloned machine, find the script in the temporary directory and manually execute the script to observe it’s output.